Nguồn: Tại đây
Trong bối cảnh blockchain hiện tại, việc lựa chọn một khung blockchain thường phải đối mặt với các sự đánh đổi:
Cosmos-SDK và CosmWasm, mặc dù phức tạp và chứa đầy nợ kỹ thuật, cung cấp quyền truy cập vào Single-Slot Finality và IBC.
Move khám phá một cách tiếp cận mới trong thiết kế hợp đồng thông minh, nhưng hệ sinh thái lại thiếu công cụ và có nhiều phiên bản khác nhau gây nhầm lẫn.
EVM có công cụ hoàn thiện, nhưng việc khởi chạy L1 hoặc L2 của riêng bạn liên quan đến việc sử dụng một nhánh geth đặc biệt, cuối cùng chỉ trở thành một phần nào đó “tương thích EVM”.
Những Bài Học Từ Polaris
Sau khi phân tích dữ liệu testnet kỹ lưỡng, chúng tôi đã cẩn thận đánh giá các điểm mạnh và yếu của Polaris. Có vẻ như chúng tôi đang kết hợp các khía cạnh tốt nhất của cả hệ sinh thái CometBFT/Cosmos và EVM, nhưng cũng mang theo những nhược điểm của chúng, điều này cuối cùng đã đưa chúng tôi trở lại bàn vẽ.
Vấn Đề Mempool Của CometBFT
Một phần lớn sự tắc nghẽn nghiêm trọng trên Artio là do các vấn đề đã được ghi nhận rõ ràng với mempool của CometBFT. Chúng tôi nhận thấy rằng những vấn đề này đã cản trở việc bao gồm giao dịch và làm gián đoạn sự hoạt động đúng của thị trường phí EIP-1559, khiến chuỗi trở nên khó sử dụng vào những thời điểm nhất định.
Precompiles Hiệu Quả, Nhưng Thiếu Kinh Nghiệm Của Nhà Phát Triển
Mặc dù đã đạt được cải tiến đáng kể trong hiệu suất thực thi (khoảng 500%) thông qua precompiles, nhưng trải nghiệm của nhà phát triển đã bị ảnh hưởng đáng kể. Các công cụ như foundry không luôn hoạt động như mong đợi. Chạy forge script gây ra các vấn đề, vì revm cục bộ thiếu logic cần thiết để thực thi các giao dịch này.
Duy Trì Một Nhánh Geth Khó Hơn Bạn Nghĩ
Chúng tôi nhận ra rằng duy trì các khách hàng thực thi nhánh không bền vững trong thời gian dài. Các nhánh nhanh chóng tụt hậu so với phiên bản phát hành mới nhất, và khi kết hợp với logic tùy chỉnh, thường đòi hỏi một mức độ hỗ trợ kỹ thuật đáng kể để duy trì.
Thêm vào sự đa dạng khách hàng và bạn đang duy trì nhiều nhánh, trên nhiều ngôn ngữ lập trình khác nhau, trong khi cố gắng tuyển dụng các kỹ sư cấp cao trong một thị trường cạnh tranh. Điều mà hầu hết các nhà phát triển chuỗi alt-L1/L2 EVM mong muốn là sự ổn định và các công cụ đi kèm với EVM. Tại sao phải nhảy qua tất cả các vòng lặp chạy nhánh để dán thuật toán đồng thuận mới sáng bóng của bạn, khi bạn có thể chỉ cần kết nối docker pull reth:latest cuối cùng và bạn đã hoàn tất.
Chào Mừng Đến Với BeaconKit
BeaconKit là một khung modular để xây dựng các khách hàng đồng thuận EVM, cho phép các nhà phát triển ra mắt cả chuỗi layer 1 và 2 EVM với đầy đủ khả năng tương thích EIP, độ cuối cùng một khe, và nhiều hơn thế nữa. Giống như người đồng cấp Golang Prysm, BeaconKit sử dụng EngineAPI để tạo điều kiện giao tiếp giữa Lớp Đồng Thuận và Lớp Thực Thi, cho phép tách rời hoàn toàn môi trường thực thi EVM khỏi CometBFT.
Các nhà vận hành có thể chạy các khách hàng thực thi không thay đổi và đạt được sự tương đồng hoàn hảo / 100% với EVM của mạng chính Ethereum. Tính đến hôm nay, chúng tôi đã thử nghiệm BeaconKit với các khách hàng thực thi sau:
- Geth: triển khai Go chính thức của giao thức Ethereum.
- Erigon: một khách hàng có hiệu suất cao hơn, nhiều tính năng, được nhánh từ go-ethereum.
- Nethermind: một khách hàng dựa trên .NET với hỗ trợ đầy đủ cho các giao thức Ethereum.
- Besu: một khách hàng cấp doanh nghiệp, được cấp phép Apache 2.0, viết bằng Java.
- Reth: một khách hàng dựa trên Rust tập trung vào hiệu suất và độ tin cậy.
- Ethereumjs: một khách hàng dựa trên Javascript được quản lý bởi Ethereum Foundation.
Thực Thi Ngay Lập Tức & Xây Dựng Optimistic Payload
Bằng cách tận dụng BeaconBlock tùy chỉnh của chúng tôi trên đỉnh của khối CometBFT tiêu chuẩn, BeaconKit hỗ trợ thực thi ngay lập tức. Điều này có nghĩa là các chuỗi BeaconKit có thể ép buộc rằng các Validators ký lên StateRoot đề xuất trước khi chấp nhận khối, đơn giản hóa đáng kể quy trình xác minh khối và giảm thời gian từ BlockGossip đến Inclusion. Điều này cho phép abci.FinalizeBlock cực kỳ nhanh chóng và mở đường cho Xây Dựng Optimistic Payload.
“Điều này một mình có thể giảm thời gian khối lên tới 40%.”
Thực thi ngay lập tức cho phép chúng tôi bắt đầu xây dựng payload thực thi (khối EVM) trước, vì chúng tôi biết StateRoot của khối hiện tại trước khi nó được hoàn thiện. Điều này một mình có thể giảm thời gian khối lên tới 40%.
Cosmos Modules? Protobuf Encoding? F*** That.
Mặc dù mục tiêu của Cosmos-SDK là cho phép các module tương tác với nhau, chúng tôi nhận thấy rằng việc kết hợp các module này khiến việc triển khai mọi thứ theo cách chúng tôi mong muốn trở nên cực kỳ khó khăn. Cách SDK hiện đang được triển khai rất gò bó và gần như không có sự linh hoạt nào. Điều này không phù hợp với chúng tôi, vì vậy chúng tôi đã gỡ bỏ tất cả và tự làm lại.
Các Module Cosmos? Chưa Bao Giờ Nghe Nói Về Chúng.
BeaconKit không sử dụng bất kỳ module Cosmos tiêu chuẩn nào và cho phép các nhà phát triển chuỗi đưa logic tùy chỉnh vào từng trường hợp cụ thể, cho phép các quy tắc Xác Thực Khối Tùy Chỉnh, logic Xử Lý Khối Tùy Chỉnh, và nhiều hơn thế nữa.
“Chờ đã, bạn cần AccountKeeper? BankKeeper?? 🤦 Ughh…”, là một phàn nàn phổ biến của các nhà phát triển Cosmos. Triển khai logic staking tùy chỉnh không nên biến thành một dự án nghiên cứu kéo dài 6 tháng nơi chúng tôi phải gỡ bỏ mọi thứ, và chúng tôi đã đảm bảo rằng điều này không xảy ra với BeaconKit. Trong quá trình thiết kế BeaconKit, chúng tôi đã đưa SSZ (Simple-SerialiZe Encoding) trở thành công dân hạng nhất và loại bỏ hoàn toàn sự hỗn loạn của protobuf. Điều này cho phép triển khai EIP-4788, cho phép chúng tôi xác minh và chứng minh dữ liệu lớp đồng thuận trên lớp thực thi mà không cần sự cho phép.
Ví dụ, Proof-of-liquidity yêu cầu chuỗi chuyển tiếp thông tin đề xuất của validator vào môi trường thực thi, và điều này được bao gồm trong BeaconBlockRoot. Ngoài các trường hợp sử dụng của riêng chúng tôi, chúng tôi hình dung một thế giới nơi những người xây dựng khác đang phát triển L1 hoặc L2 của riêng họ có thể muốn có quyền truy cập tương tự vào thông tin này, đó là lý do tại sao 4788 là một cột mốc quan trọng.
Blobs? Rollups? Tất Nhiên.
EIP-4844 đã được đưa vào cụ thể để mở rộng tương lai của các chuỗi dựa trên BeaconKit. Chúng tôi đã thấy những lợi ích của việc có một lớp sẵn sàng cho dữ liệu trên mạng chính, và cách điều đó cho phép L2. Ngoài việc hỗ trợ EIP-4844, các nhà phát triển chuỗi có thể sử dụng BeaconKit với bất kỳ động cơ đồng thuận tương thích ABCI 2.0 nào, và do đó có thể dễ dàng được tích hợp với Rollkit để tạo ra các giải pháp layer-2 mạnh mẽ.
Các Quy Tắc và Loại Xác Thực Khối Tùy Chỉnh
Khi tích hợp BeaconKit, các nhà phát triển có thể dễ dàng giới thiệu các quy tắc xác thực khối tùy chỉnh để cho phép một số hành vi nhất định trong cả các Khối EVM và Beacon. Ví dụ, một nhà phát triển chuỗi có thể chọn triển khai một quy tắc xác thực khối tùy chỉnh cho phép họ từ chối bất kỳ ExecutionPayload (khối EVM) nào không tuân thủ một thứ tự giao dịch nhất định, như một ví dụ đơn giản.
Cuối cùng, những quy tắc xác thực dựa trên plugin này có thể được mở rộng để tích hợp các cơ chế như PEPC, hữu ích cho việc re-staking và các ứng dụng cross-chain.
Điều Gì Sẽ Đến?
BeaconKit hiện có sẵn mã nguồn dưới giấy phép BUSL 1.1, nhưng sẽ chuyển sang MIT trong tương lai. Nếu bạn quan tâm đến việc sử dụng BeaconKit cho dự án L1 hoặc L2 tiếp theo của mình, hãy liên hệ với chúng tôi! Liên kết đến repo tại đây: https://github.com/berachain/beacon-kit.
