Tác giả: KarenZ, Foresight News
Vào ngày 25 và 26 tháng 6, mạng chính Base đã liên tục hai ngày gặp phải tình trạng dừng sản xuất khối. Base sau đó đã xem xét lại và cho biết, cả hai lần gián đoạn đều xuất phát từ cùng một vấn đề cốt lõi: lỗi trong logic xây dựng khối của bộ sắp xếp (sequencer).
Theo thông tin xem xét lại của Base, lỗ hổng này khiến trạng thái nhật ký lỗi thời vẫn tồn tại sau khi xác minh giao dịch thất bại, ảnh hưởng đến việc tính toán Gas cho các giao dịch hợp lệ tiếp theo, từ đó tạo ra các khối chuyển trạng thái không hợp lệ, khiến toàn bộ mạng L2 ngừng tạo khối. Sau lần dừng đầu tiên, đội ngũ chính thức đã khắc phục vấn đề bằng bản vá và khôi phục việc sản xuất khối. Ngoài ra, cụm sắp xếp (sequencer cluster) của Base tồn tại điều kiện cạnh tranh trong quá trình khởi động lại, gây cản trở việc đồng bộ hóa khôi phục, cũng trở thành nguyên nhân gián tiếp dẫn đến việc tạm ngừng hoạt động ngắn vào ngày hôm sau.
Cùng trong khung thời gian đó, việc triển khai mạng chính của B20 mà Base dự định thúc đẩy cũng đã bị tạm hoãn.
Vào ngày 26 tháng 6, Base cho biết, "Do ảnh hưởng của các vấn đề ổn định mạng gần đây, sẽ hoãn việc kích hoạt mạng chính của B20 Activation Registry để đảm bảo quá trình triển khai diễn ra suôn sẻ."
Bước đi này thoạt nhìn có vẻ thận trọng, nhưng lại cho thấy vị trí của B20 rất quan trọng. Nó không phải là một bản cập nhật ứng dụng biên, mà là cổng vào cấp mạng mà Base dự định đón nhận stablecoin, RWA và nhiều phát hành tài sản hơn. Cổng vào càng gần với tầng hạ tầng, càng không thể chỉ xem xét chức năng có đầy đủ hay không, mà còn phải xem xét sự ổn định của mạng lưới, nhịp độ nâng cấp và thiết kế quyền hạn có thể cùng nhau chịu đựng được hay không.
B20: Giao diện phát hành token gốc của Base
B20 thuộc một phần của bản nâng cấp mạng Beryl của Base. Ba thay đổi cốt lõi của Beryl là: giới thiệu B20, rút ngắn thời gian xác nhận cuối cùng để rút tiền bằng chứng đơn lẻ phổ biến từ 7 ngày xuống 5 ngày, và cải thiện hiệu suất lưu trữ và thông lượng của nút thông qua Reth V2.
B20 trước tiên có thể được hiểu theo cách đơn giản nhất: Nó là phiên bản ERC-20 của Base, nhưng đưa nhiều logic mà trước đây các dự án tự viết, tự kiểm tra và tự bảo trì, vào các thành phần gốc của Base.
Token ERC-20 thông thường thường được triển khai bởi một hợp đồng thông minh để chứa các logic như số dư, ủy quyền, chuyển tiền, phát hành thêm, hủy bỏ, v.v. Điểm khác biệt của B20 là, token vẫn có địa chỉ trên chuỗi và cũng có thể được ví, trình duyệt và giao thức DeFi gọi theo cách tương thích với ERC-20; nhưng B20 sử dụng chương trình biên dịch sẵn Rust thay vì hợp đồng thông minh EVM để triển khai, do đó tốc độ nhanh hơn, chi phí thấp hơn.
Nói cách khác, bên tích hợp bên ngoài nhìn thấy là giao diện token tương thích ERC-20, còn bên phát hành kết nối vào là cơ sở hạ tầng phát hành token được tích hợp sẵn của Base.
Đây cũng là lý do B20 được gọi là tiêu chuẩn token gốc của Base. Tài liệu chính thức của Base viết, B20 là phiên bản ERC-20 riêng của hệ sinh thái Base, hỗ trợ các lệnh gọi và sự kiện tiêu chuẩn ERC-20 như chuyển tiền, ủy quyền chuyển tiền cho bên thứ ba, phê duyệt hạn mức, truy vấn số dư, allowance; đồng thời bổ sung các khả năng mở rộng như ghi chú (memo), đúc/hủy, kiểm soát truy cập theo chiến lược, tạm dừng chi tiết và ERC-2612 permit (ủy quyền bằng chữ ký).
Ở đây cần giải thích riêng về ERC-2612 permit, tức khả năng ủy quyền bằng chữ ký. Trong ERC-20 thông thường, nếu người dùng muốn một hợp đồng nào đó sử dụng token của mình, thường phải gửi một giao dịch approve trước, giao dịch này cần trả phí Gas. ERC-2612 permit cho phép người dùng ký ngoại tuyến bằng ví để hoàn tất việc ủy quyền, sau đó dự án hoặc ứng dụng gửi chữ ký này lên chuỗi. Người dùng không cần tự gửi giao dịch approve riêng biệt, giảm một thao tác approve trên chuỗi.
Nếu dùng một phép ẩn dụ thực tế hơn, ERC-20 truyền thống giống như mỗi bên phát hành tự lấy một bộ bản vẽ tiêu chuẩn để xây nhà, chất lượng thi công phụ thuộc vào đội ngũ phát triển và kiểm toán của từng bên. B20 giống như Base cung cấp một cấu trúc đúc sẵn thống nhất hơn: lối vào, giao diện và chức năng chính đều được tiêu chuẩn hóa, bên phát hành vẫn quyết định tham số tài sản và quy tắc quản lý, nhưng khả năng hạ tầng đến từ cùng một bộ thành phần cấp mạng.
Xét về cách triển khai, B20 cũng không phải là để các dự án sao chép tùy ý một hợp đồng token. Tất cả token B20 đều được tạo thông qua precompile B20 Factory singleton, khi tạo sẽ chọn biến thể Asset hoặc Stablecoin, và truyền vào các tham số như tên, ký hiệu, quản trị viên ban đầu, giới hạn cung, lệnh gọi khởi tạo, v.v.
Vì vậy, trọng tâm của B20 không phải là biến việc phát hành token thành một nút giao diện đẹp hơn, mà là đẩy việc phát hành token từ "mỗi dự án tự viết hợp đồng" tiến tới "Base cung cấp giao diện phát hành thống nhất và khả năng chiến lược tích hợp sẵn". Nó làm giảm chi phí xây dựng lặp lại các chức năng tiêu chuẩn, đồng thời đưa việc phát hành tài sản kết nối sâu hơn vào việc nâng cấp hạ tầng của chính Base.
Điểm quan trọng thực sự nằm ở "kiểm soát": Quyền hạn, danh sách trắng/đen, đóng băng và ghi chú
Các công cụ dành cho nhà phát hành được Base chính thức liệt kê bao gồm: Tương thích ERC-20, ERC-2612 permit, Kiểm soát truy cập dựa trên vai trò, đúc/hủy, giới hạn cung tùy chọn, chiến lược chuyển tiền, hủy số dư của địa chỉ bị đóng băng theo chính sách, và memo giao dịch chuyển tiền.
Những chức năng này trông có vẻ thiên về kỹ thuật, nhưng khi đặt vào công việc thực tế của bên phát hành, chủ yếu ứng với ba loại vấn đề: Ai có quyền quản lý token, những địa chỉ nào có thể tham gia lưu thông, và làm thế nào để các thao tác trên chuỗi để lại hồ sơ có thể truy xuất.
Thứ nhất, quyền quản lý có thể được phân tầng. Ai có thể phát hành thêm, hủy, tạm dừng chuyển tiền, khôi phục chuyển tiền, sửa đổi siêu dữ liệu, không cần trộn lẫn trong cùng một quyền quản trị viên. Tài liệu B20 liệt kê các vai trò như quản trị viên mặc định, phát hành thêm, hủy, tạm dừng, khôi phục, quản lý siêu dữ liệu, v.v. Bằng cách này, bên phát hành có thể giao các thao tác khác nhau cho các vai trò khác nhau kiểm soát, giảm rủi ro khi một khóa riêng tư đơn lẻ hoặc quyền quản trị viên duy nhất quá lớn.
Thứ hai, phạm vi lưu thông của token có thể bị ràng buộc bởi chiến lược. Policy Registry của B20 hỗ trợ danh sách trắng và danh sách đen. Bên phát hành có thể ràng buộc riêng biệt địa chỉ gửi chuyển tiền, địa chỉ nhận chuyển tiền, và bên gọi (caller) thay mặt khởi tạo chuyển tiền trong trường hợp transferFrom; trong trường hợp phát hành thêm, cũng có thể ràng buộc địa chỉ nhận token mới đúc. Nói đơn giản, B20 có thể quản lý "ai chuyển ra, ai nhận, ai thay người khác khởi tạo chuyển tiền", cũng có thể quản lý "token mới sẽ được phát hành đến tay ai". Khả năng này đặc biệt quan trọng với stablecoin, RWA và tài sản chịu sự quản lý, vì những tài sản này thường cần địa chỉ KYC, bên nhận bị hạn chế, khả năng đóng băng và đường xử lý tiếp theo.
Thứ ba, các thao tác trên chuỗi có thể để lại chỉ mục nghiệp vụ. B20 hỗ trợ memo, tức trường ghi chú bytes32 đính kèm trên thao tác token. Nó sẽ không thay thế sổ cái ngoài chuỗi đầy đủ, nhưng có thể đóng vai trò là điểm kết nối giữa giao dịch trên chuỗi và hồ sơ ngoài chuỗi. Ví dụ, một khoản thanh toán trên chuỗi tương ứng với một số đơn hàng, một lần mua lại tương ứng với một khoản thanh toán hậu cần, một lần phát hành tương ứng với một loạt hồ sơ phân phối, memo có thể giúp bên phát hành, ví, bên lưu ký hoặc dịch vụ lập chỉ mục đối chiếu các thông tin này.
Tóm tắt
Nhưng phải nói rõ, B20 chỉ là đưa công cụ đến trước mặt bên phát hành, không tự động thay bên phát hành hoàn thành việc tuân thủ. Mỗi phạm vi chiến lược khi tạo token mặc định đều là ALWAYS_ALLOW, tức mặc định cho phép tất cả. Nếu bên phát hành không chủ động thiết lập danh sách trắng, danh sách đen hoặc các hạn chế khác, token B20 này sẽ lưu thông tự do như một token mở thông thường.
Nói cách khác, B20 cho bên phát hành khả năng "đặt quy tắc", nhưng quy tắc có nên đặt, đặt như thế nào, vẫn phải do bên phát hành tự hoàn thành.
Điều này cũng giải thích tại sao B20 chủ yếu hướng đến các bên phát hành stablecoin, RWA và những người tạo token tài sản khác. Stablecoin cần khả năng quyền hạn và đóng băng, RWA cần hạn chế chuyển nhượng và ánh xạ hồ sơ ngoài chuỗi, các tài sản khác cần chi phí phát hành tiêu chuẩn hóa thấp hơn. Ba nhu cầu trông có vẻ khác nhau, nhưng cốt lõi đều hướng đến cùng một vấn đề: Một L2 có thể cung cấp đủ thống nhất, đủ kiểm soát, đồng thời có thể được hệ sinh thái ERC-20 hiện có kết nối trơn tru hay không.
