Cơ bản
Giao ngay
Giao dịch tiền điện tử một cách tự do
Giao dịch ký quỹ
Tăng lợi nhuận của bạn với đòn bẩy
Chuyển đổi và Đầu tư định kỳ
0 Fees
Giao dịch bất kể khối lượng không mất phí không trượt giá
ETF
Sản phẩm ETF có thuộc tính đòn bẩy giao dịch giao ngay không cần vay không cháy tải khoản
Giao dịch trước giờ mở cửa
Giao dịch token mới trước niêm yết
Futures
Truy cập hàng trăm hợp đồng vĩnh cửu
TradFi
Vàng
Một nền tảng cho tài sản truyền thống
Quyền chọn
Hot
Giao dịch với các quyền chọn kiểu Châu Âu
Tài khoản hợp nhất
Tối đa hóa hiệu quả sử dụng vốn của bạn
Giao dịch demo
Giới thiệu về Giao dịch hợp đồng tương lai
Nắm vững kỹ năng giao dịch hợp đồng từ đầu
Sự kiện tương lai
Tham gia sự kiện để nhận phần thưởng
Giao dịch demo
Sử dụng tiền ảo để trải nghiệm giao dịch không rủi ro
Launch
CandyDrop
Sưu tập kẹo để kiếm airdrop
Launchpool
Thế chấp nhanh, kiếm token mới tiềm năng
HODLer Airdrop
Nắm giữ GT và nhận được airdrop lớn miễn phí
Launchpad
Đăng ký sớm dự án token lớn tiếp theo
Điểm Alpha
Giao dịch trên chuỗi và nhận airdrop
Điểm Futures
Kiếm điểm futures và nhận phần thưởng airdrop
Đầu tư
Simple Earn
Kiếm lãi từ các token nhàn rỗi
Đầu tư tự động
Đầu tư tự động một cách thường xuyên.
Sản phẩm tiền kép
Kiếm lợi nhuận từ biến động thị trường
Soft Staking
Kiếm phần thưởng với staking linh hoạt
Vay Crypto
0 Fees
Thế chấp một loại tiền điện tử để vay một loại khác
Trung tâm cho vay
Trung tâm cho vay một cửa
Thêm
Full Chain Game 101: Hợp đồng biên dịch trước
**Hợp đồng biên dịch sẵn 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:
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:
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.
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à tinh tế, đồng thời việc chờ EIP thông qua không phải là một vấn đề thực tế.
Đ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.