Full Chain Game 101: Hợp đồng biên dịch trước

Nguồn: Gametaverse

Hiện tại, hai công cụ trò chơi toàn chuỗi tiềm năng nhất, Curio và Argus, chọn cải thiện hiệu suất truy vấn của trạng thái trò chơi và tăng khả năng thích ứng với các trò chơi toàn chuỗi cụ thể thông qua các hợp đồng được biên dịch trước của các nút tùy chỉnh. -biên dịch?Hợp đồng và tại sao các hợp đồng được biên dịch trước có thể cải thiện hiệu suất? Để kết luận, vui lòng đọc bài báo khoa học phổ biến này: Các hợp đồng được biên dịch trước của các trò chơi toàn chuỗi 101.

**Hợp đồng biên dịch trước là gì? **

Các hợp đồng được biên dịch trước là một phương pháp thỏa hiệp được sử dụng trong EVM để cung cấp các chức năng thư viện phức tạp hơn (thường được sử dụng cho các hoạt động phức tạp như mã hóa và băm). Nó cũng có thể được hiểu là một hợp đồng đặc biệt và các chức năng này không phù hợp để viết opcode. Chúng phù hợp với các hợp đồng đơn giản nhưng được gọi thường xuyên hoặc các hợp đồng được cố định về mặt logic nhưng cần nhiều tính toán. Các hợp đồng biên dịch trước được triển khai bằng cách sử dụng mã máy khách của nút và vì chúng không yêu cầu EVM nên chúng chạy nhanh. Nó cũng ít tốn kém hơn cho nhà phát triển so với việc sử dụng các chức năng chạy trực tiếp trong EVM.

Như có thể thấy từ đoạn mã sau, hàm chạy trong hợp đồng evm.go có hai nhánh: nhánh đầu tiên là khởi tạo tham số chỉ mục thông qua chỉ mục được biên dịch trước để chỉ định hợp đồng được biên dịch trước và nhánh thứ hai là chỉ định hợp đồng được biên dịch sẵn hợp đồng nếu nó không phải là hợp đồng được biên dịch trước. evm đó sẽ được gọi.

// run chạy hợp đồng đã cho và đảm nhiệm việc chạy các biên dịch trước với dự phòng cho trình thông dịch mã byte. func run(evm *EVM, hợp đồng *Hợp đồng, đầu vào []byte, readOnly bool) ([]byte, lỗi) { nếu hợp đồng.CodeAddr != nil { biên dịch trước := PrecompiledContractsHomestead nếu evm.ChainConfig().IsByzantium(evm.BlockNumber) { tiền biên dịch = PrecompiledContractsByzantium } if p := precompiles[*contract.CodeAddr]; p != nil { trả về RunPrecompiledContract(p, đầu vào, hợp đồng) } } cho _, trình thông dịch := phạm vi evm.interpreters { nếu thông dịch viên.CanRun(hợp đồng.Code) { if evm.interpreter != trình thông dịch { // Đảm bảo rằng con trỏ thông dịch được đặt trở lại // thành giá trị hiện tại khi trả về. chức năng trì hoãn (i Thông dịch viên) { evm.interpreter = tôi }(evm.interpreter) evm.interpreter=thông dịch viên } trả lại thông dịch viên.Run (hợp đồng, đầu vào, chỉ đọc) } } trả về con số không, ErrNoCompatibleInterpreter }

Nếu diễn đạt bằng đồ thị thì logic cụ thể như sau:

Vậy nút cổ chai của hợp đồng biên dịch sẵn nằm ở đâu?

Ethereum hiện có tám hợp đồng được biên dịch sẵn:

1. ECRecover - Khôi phục địa chỉ tương ứng thông qua chữ ký
2. SHA256 - Tính hàm băm SHA256
3. RIPEMD160 - Tính hàm băm RIPEMD160
4. Identity - trả về giá trị ban đầu của dữ liệu đầu vào
5. ModExp - Thực hiện phép lũy thừa Modulo
6. ECAdd - Bổ sung điểm đường cong elip
7. ECMul - Phép nhân điểm trên đường cong elip
8. ECPairing - hoạt động ghép nối, xác minh điểm đường cong elip

Bạn có thể thấy rằng các hợp đồng được biên dịch trước từ thứ nhất đến thứ tư cung cấp chữ ký cơ bản, hàm băm và các chức năng mã hóa khác, và hợp đồng thứ năm đến thứ tám cung cấp các hoạt động đường cong elip, có liên quan đến zk-snark.

Vì vậy, câu hỏi đặt ra là, tại sao tiền biên dịch Ethereum chỉ hỗ trợ tám hợp đồng được biên dịch sẵn? Và tại sao không cấy trực tiếp ECS (khung của toàn bộ trò chơi chuỗi) vào hợp đồng được biên dịch sẵn của Ethereum?

Trên thực tế, có ba lý do chính:

1. Việc phụ thuộc quá nhiều vào các hợp đồng được biên dịch sẵn sẽ làm giảm mức độ phân cấp của toàn bộ nền tảng:

Trước hết, mã của hợp đồng được biên dịch trước cần được tích hợp vào mã nút máy khách, điều này làm tăng độ phức tạp của máy khách. Thứ hai, các nút xác minh có thể lọc ra việc tính toán các hợp đồng được biên dịch trước vì lý do bảo mật, vì vậy hầu hết các yêu cầu đối với các hợp đồng được biên dịch trước đều được hoàn thành bởi các nút đầy đủ. Hiện tại, chỉ có 4000-6000 nút đầy đủ Ethereum trên thế giới và có 500.000 nút xác minh các nút, thực sự tập trung hơn nhiều so với các hợp đồng không được biên dịch trước.

2. Việc bổ sung và sửa đổi các hợp đồng được biên dịch sẵn yêu cầu nâng cấp hard fork, không dễ để phát triển linh hoạt.

Việc hỗ trợ các hợp đồng được biên dịch trước yêu cầu quy trình EIP. Ví dụ: EIP-196 thêm hai hợp đồng được biên dịch sẵn là ECADD() và ECMUL() trên đường cong alt_bn128. EIP-197 thêm chức năng Ghép nối trên đường cong alt_bn128. Về cơ bản, đó là cung cấp quyền riêng tư trên Ethereum để được hỗ trợ và toàn bộ quy trình EIP kéo dài và tao nhã, đồng thời việc đợi EIP thông qua không phải là một vấn đề thực tế.

3. Rất khó để tương tác và kết hợp các hợp đồng được biên dịch sẵn và khả năng mở rộng kém.

Điều này không có gì nhiều để giải thích, nó rất trực quan.

Hợp đồng được biên dịch trước đóng vai trò gì trong toàn bộ trò chơi chuỗi?

Các hợp đồng được biên dịch trước bỏ qua EVM và thực thi trực tiếp thông qua các nút, điều này có thể cải thiện hiệu quả tính toán, nhưng đồng thời làm giảm mức độ phân cấp của toàn bộ chuỗi. Biên dịch trước logic cốt lõi của các trò chơi được sử dụng thường xuyên có thể tối ưu hóa hiệu suất của các trò chơi đó. Các loại trò chơi khác nhau có logic chính khác nhau. Do đó, đối với chuỗi chuyên dụng của một loại trò chơi nhất định, thiết kế được biên dịch trước của nó có thể tối ưu hóa cao nhu cầu của loại trò chơi này. Trong quá trình lặp lại trò chơi, tổ hợp hợp đồng được biên dịch trước hiệu quả nhất sẽ dần được tối ưu hóa.