Đây là sơ đồ đơn giản của các light client hoạt động trong cầu kết nối:
Lưu ý, ngoài các hợp đồng thông minh mà triển khai các light client thì chúng tôi còn có hai dịch vụ khác, được gọi là Relay (rơ-le), thường gửi các header cho các light client. Eth2NearRelay gửi mỗi header cho hợp đồng EthOnNearClient, trong khi Near2EthRelay gửi một header mỗi 4 giờ vào hợp đồng EthOnNearClient. Đối với cặp hợp đồng EthOnNearClient và NearOnEthClient thì có thể có một số cặp dịch vụ Eth2NearRelay và Near2EthRelay. Mỗi người bảo trì của cầu kết nối có thể chạy các cặp dịch vụ của họ. Các cặp dịch vụ này có thể cạnh tranh với nhau, chúng sẽ cố gửi các khối giống nhau cùng một lúc và chỉ có một thành công mỗi lần hoặc sao lưu lẫn nhau, một số dịch vụ sẽ chỉ gửi khối nếu các khối khác không gửi trong thời gian quy định. Việc thực hiện các dịch vụ hiện tại của chúng tôi chạy ở chế độ đầu tiên.
EthOnNearClient
Như chúng tôi đã chia sẽ về EthOnNearClient, nó là một phiên thực hiện của light client Ethereum trong Rust như là một hợp đồng NEAR. Nó chấp nhận các Eethereum header và duy trì chuỗi canonical, nó giả định rằng các khối có đặc điểm finalized_gc_threshold không thể rời khỏi chuỗi canonical, và nó ghi nhớ hashes_gc_threshold của các khối từ chuỗi canonical, nơi hashes_gc_threshold >= finalized_gc_threshold. Giá trị mặc định của finalized_gc_threshold = 46k mà nó tương ứng khoảng 7 ngày giá trị của các header. Điều này được thực hiện để trạng thái của EthOnNearClient không phát triển đến vô tận. Hãy nhớ rằng điều này trong NEAR là yêu cầu có một số mã thông báo bị khóa nhất định để có thể sử dụng được trạng thái đó (xem thêm tại đây), và nó sẽ yêu cầu một lượng lớn và ngày càng tăng lượng khóa mã thông báo nếu chúng ta lưu trữ các hash của mỗi khối Ethereum canonical header trong một hợp đồng duy nhất. Do đó chúng tôi lưu trữ một số giới hạn hash của Ethereum header. Một kết quả của cầu kết nối chỉ có thể được sử dụng để chứng minh sự kiện đã xảy ra trong thời gian này. Vì vậy, nếu bạn bắt đầu chuyển ERC20 từ Ethereum đến NEAR, hãy đảm bảo hoàn thành trong vòng 7 ngày nếu nó bị gián đoạn giữa chừng.
Một sắc thái quan trọng khác của EthOnNearClient là cách nó xác minh Ethereum header. Nó sẽ không thể xác minh Ethereum Pow trực tiếp trong hợp đồng vì nó sẽ yêu cầu lưu trữ các tập tin DAG của Ethereum, thứ mà sẽ yêu cầu sử dụng bộ nhớ cấm. Tháng 5 mắn thay, mỗi khối Ethereum chỉ sử dụng một tập hợp con của các yếu tố từ tập tin DAG, và chỉ có một tập tin DAG cho mỗi Ethereum epoch. Hơn nữa, tập tin DAG có thể được tính toán trước cho các epoch tương lai. Chúng tôi tính toán trước tập tin DAG cho khoảng 4 năm và hợp nhất chúng. Hợp đồng EthOnNearClient sau đó ghi nhớ các merkle gốc của các tập tin DAG cho 4 năm tiếp theo sau khi khởi tạo. EthOnNearClient sau đó chỉ cần nhận được các Ethereum header, các yếu tố DAG và các bằng chứng merkle của các yếu tố này, cho phép nó xác minh Pow mà không cần toàn bộ tập tin DAG trong bộ nhớ. Chúng tôi đã tiếp cận phương pháp này từ EOS Bridge được sử dụng bởi Kyber network, và chúng tôi thậm chí tái sử dụng một số mã của họ. Tháng 5 mắn thay, việc xác minh của Ethereum header chỉ sử dụng 1/3 trong giới hạn tối đa của gas giao dịch và 1/10 của giới hạn gas của khối.
NearOnEthClient
NearOnEthClient là một phiên thực hiện của khối NEAR light client trong Solidity như một hợp đồng Eethereum. Không giống như EthOnNearClient nó không cần phải xác minh mỗi khối NEAR header và có thể bỏ qua hầu hết chúng miễn là nó kiểm tra ít nhất một header trong một NEAR epoch, nó có khoảng 43k khối và kéo dài khoảng nửa ngày. Kết quả là EthOnNearClient có thể ghi nhớ hash của tất cả các khối NEAR header đã gửi trong lịch sử, vì vậy nếu bạn đang thực hiện một phiên chuyển từ NEAR đến Ethereum nhưng nó bị gián đoạn , bạn không cần phải lo lắng nhiều, bạn có thể tiếp tục nó bất cứ lúc nào và thậm chí cả tháng sau đó cũng được. Một thuộc tính hữu ích của NEAR light client là tất cả NEAR header chứa một merkle gốc tính từ tất cả các khối header trước nó. Kết quả là nếu bạn có một NEAR header, bạn có thể xác minh hiệu quả bất kỳ sự kiện xảy ra trong bất kỳ header trước nó.
Một thuộc tính hữu ích khác của NEAR light client là nó chỉ chấp nhận các khối đã hoàn thành và các khối cuối không thể rời khỏi chuỗi canonical trong NEAR. Điều này có nghĩa là NearOnEthClient không cần lo lắng về việc fork.
Tuy nhiên, NEAR sử dụng ED25519 để ký thông báo của các Validators người mà sẽ xác nhận các khối và chữ ký này không có sẵn như là một biên dịch EVM. Nó làm cho sự xác minh của tất cả các chữ ký của một NEAR header trở nên tốn kém. Vì vậy, về mặt kỹ thuật chúng tôi không thể xác minh một NEAR header trong một lệnh gọi hợp đồng đến NearOnEthClient. Do đó chúng tôi áp dụng phương pháp optimistic nơi mà NearOnEthClient kiểm tra tất cả mọi thứ trong NEAR header ngoại trừ chữ ký. Sau đó bất cứ ai có thể thử thách một chữ ký trong một header đã gửi trong một cửa sổ 4 giờ thách thức. Thử thách yêu cầu xác minh của một chữ ký Ed25519 duy nhất mà có chi phí khoảng 500k ethereum gas (vô cùng tốn kém, nhưng có thể). Người dùng gửi NEAR header phải đăng một trái phiếu bằng mã thông báo Ethereum và một thử thách thành công phải đốt một nửa trái phiếu đã đăng và trả lại một nửa kia cho người thách thức. Khoản trái phiếu phải đủ lớn để trả phí gas thậm chí là nếu giá gas tăng theo cấp số nhân trong 4 giờ. Ví dụ, một trái phiếu là 20 eth sẽ phải chi trả giá gas tăng lên đến 20000 gwei. Phương pháp này đòi hỏi phải có một dịch vụ Watchdog để giám sát các NEAR header đã gửi và thách thức bất kỳ header với chữ ký không hợp lệ. Đối với bảo mật bổ sung, người dùng độc lập có thể chạy một số dịch vụ Watchdog.
Một khi EIP665 được chấp nhận, Ethereum sẽ có chữ ký Ed25519 có sẵn như là biên dịch EVM. Điều này sẽ làm cho dịch vụ giám sát và việc thách thức trong 4 giờ trở nên không cần thiết.
Ở mức tối thiểu, Rainbow Bridge bao gồm các hợp đồng EthOnNearClient và NearOnEthClient và ba dịch vụ: Eth2NearRelay, Near2EthRelay và Watchdog. Chúng tôi có thể tranh luận rằng điều này đã tạo thành một cầu nối vì chúng tôi đã thiết lập một liên kết mật mã giữa hai blockchain, nhưng thực tế nó yêu cầu một phần lớn mã bổ sung để khiến các nhà phát triển ứng dụng thậm chí cân nhắc sử dụng Rainbow Bridge cho các ứng dụng của họ.
Provers
Điều mà có thể làm cho các client hữu ích hơn là khả năng chứng minh rằng điều gì đó đã xảy ra cụ thể trên một blockchain. Để làm được điều đó, chúng tôi thực hiện hợp đồng NEAR EthOnNearProver trong Rust và hợp đồng Ethereum NearOnEthProver trong Solidity. EthOnNearProver có thể xác minh các sự kiện Ethereum, trong khi hợp đồng NearOnEthProver có thể xác minh kết quả thực hiện của hợp đồng NEAR. Cả hai hợp đồng EthOnNearProver và NearOnEthProver được thực hiện riêng biệt từ EthOnNearClient và NearOnEthClient vì nhiều lý do:
Tách các mối quan tâm: Khách hàng chịu trách nhiệm theo dõi các header của blockchain header, trong khi các prover chịu trách nhiệm xác minh thông tin mã hóa cụ thể.
Khả năng mở rộng: Từ khi NEAR là một blockchain sharded, nếu một trường hợp nhất định của cầu nối trở nên rất phổ biến, người dùng sẽ có thể theo chúng bằng cách triển khai nhiều bản sao của một provers đã cho.
Đặc trưng: Ngoài các provers được mô tả ở trên, người ta có thể triển khai các loại provers khác và có thể xác minh trạng thái của hợp đồng, nội dung cụ thể của header hoặc bao gồm một giao dịch. Ngoài ra, các phiên triển khai khác nhau của provers có thể sử dụng cho các tối ưu hóa khác nhau.
Hiện tại, chúng tôi chỉ có các sự triển khai chỉ để xác minh các sự kiện Ethereum và kết quả thực hiện hợp đồng NEAR, chúng đủ để di chuyển mã thông báo giữa các blockchain. Nhưng bất cứ ai cũng được hoan nghênh để đóng góp vào sự triển khai của prover.
(Một EthOnNearClient có thể có nhiều provers giao tiếp với nó sao chép trên nhiều shards, trong khi NearOnEthClient sẽ có một bản sao duy nhất của từng loại của các provers giao tiếp tiếp với nó).
Trường hợp sử dụng ERC20
Các provers cho phép chúng tôi xây dựng một bộ hợp đồng cho phép chuyển giao tài sản hoặc giao tiếp chuỗi chéo. Tuy nhiên, các hợp đồng này sẽ rất khác nhau tùy thuộc vào chính xác chúng tôi muốn tương tác trên cầu kết nối. Ví dụ: ERC20 yêu cầu một bộ hợp đồng hoàn toàn riêng biệt từ ERC721 hoặc chuyển mã thông báo gốc. Hiện tại, Rainbow Bridge có sự hỗ trợ ngoại vi cho chuyển mã thông báo ERC20 riêng biệt và chúng tôi sẽ thêm nhiều trường hợp sử dụng trong tương lai. Trong bài này, chúng tôi chỉ tập trung vào các trường hợp sử dụng ERC20.
Giả sử có một mã thông báo ERC20 tồn tại trên Ethereum, ví dụ DAI. Để chúng ta di chuyển chúng qua cầu kết nối thì chúng tôi cần triển khai hai hợp đồng bổ sung:
Hợp đồng Tokenlocker Ethereum thực hiện trong Solidity.
Hợp đồng MintableFungibleToken NEAR thực hiện trong Rust.
Khi người dùng muốn chuyển X lượng DAI từ Ethereum sang NEAR, trước tiên họ khóa X DAI này trong hợp đồng TokenLocker, sau đó mint x nearDAI trong hợp đồng MintableFungibleToken NEAR. Khi họ muốn chuyển một số mã thông báo trở lại từ NEAR sang Ethereum, trước tiên họ đốt Y nearDAI trong MintableFungibleToken và sau đó mở khóa Y DAI trong TokenLocker.
Hiện tại, mỗi phiên của mã thông báo ERC20 sẽ yêu cầu triển khai một cặp TokenLocker/MintableFungibleToken riêng biệt; Tuy nhiên, chúng tôi sẽ gỡ bỏ hạn chế này trong tương lai và sử dụng cùng một TokenLocker cho nhiều mã thông báo ERC20. Lưu ý rằng nếu ai đó muốn thêm hỗ trợ ERC721 hoặc một loại chuyển tài sản khác, họ sẽ cần triển khai cặp Locker/Asset tương tự với giao diện bên ngoài và triển khai nội bộ khác, nhưng thiết kế cấp cao sẽ vẫn như cũ – Locker sẽ khóa/mở khóa tài sản trong khi tài sản sẽ mint/hủy phiên bản NEAR nhất của tài sản này.
Lưu lượng sử dụng
Người dùng sẽ có thể sử dụng RainbowCLI hoặc bất kỳ ứng dụng nào tích hợp với RainbowLib, giống như ví NEAR . Trong trường hợp hiếm hoi, người nào đó có thể chọn làm việc với cầu kết nối thủ công bằng cách gọi các hợp đồng Ethereum và NEAR từ lớp hợp đồng cấp thấp. Hiện tại, chúng tôi chỉ hỗ trợ RainbowCLI, nhưng chúng tôi đang làm việc trên RainbowLib và ví tích hợp.
Từ góc độ người dùng, việc chuyển mã thông báo phải đơn giản: họ cung cấp thông tin đăng nhập, chọn người nhận và số tiền, đồng thời bắt đầu chuyển từ RainbowCLI, Ví hoặc các ứng dụng khác. Sau một thời gian, quá trình chuyển thành công và người dùng nhận được xác nhận. Tuy nhiên, đằng sau quá trình đơn giản đó, RainbowLib sẽ thực hiện các thao tác phức tạp sau:
Giả sử Alice muốn chuyển x DAIđến Bob ở NEAR blockchain và cô ấy bắt đầu chuyển từ RainbowCLI/RainbowLib.
Đầu tiên, Rainbowlib thiết lập một bộ các sự cho phép để chuyển X DAI từ Alice đến TokenLocker.
Sau đó gọi TokenLocker để lấy những mã thông báo kết quả trong “Alice khóa mã thông báo X gửi cho Bob”.
RainbowLib sau đó chờ đợi cho đến khi EthOnNearClient nhận được Ethereum header là chứa trong lệnhnày, cộng thêm 25 khối để xác nhận (xem lưu ý về Ethereum finality trong phần mở đầu).
Sau đó RainbowLib tính các bằng chứng của lệnhnày và gửi cho hợp đồng MintableFungibleToken.
Hợp đồng MintableFungibleToken sau đó xác minh rằng bằng chứng này là đúng bằng cách gọi EthOnNearProver.
EthOnNearProver trả lời bằng cách xác minh rằng các header trên chuỗi canonical của EthOnNearClient và nó yêu cầu một số xác nhận. Nó cũng tự xác minh bằng chứng.
Sau đó MintableFungibleToken giải phóng lệnh Ethereum và mints x nearDAIcho Bob, hoàn thành việc chuyển tiền.
Tương tự, RainbowLib sẽ có thể thực hiện chuyển các mã thông báo không phải ERC20 và thực hiện gọi các gọi hợp đồng.
Hard forks
Chúng tôi muốn Rainbow Bridge hiện tại không bị phá vỡ khi sự thay đổi giao thức NEAR hoặc Ethereum đang diễn ra. Và chúng tôi muốn có thể nâng cấp các hợp đồng cầu nối khi có các bản nâng cấp về hiệu năng, ví dụ: nếu EIP665 được chấp nhận. Tuy nhiên, chúng tôi không muốn nó trở nên kém tin cậy hoặc phi tập trung hơn bằng cách giới thiệu một cách tập trung vào giai đoạn ban đầu của sự nâng cấp.
Có rất nhiều mẫu proxy được phát triển bởi cộng đồng Ethereum cho phép cập nhật hợp đồng. Tuy nhiên, chúng tôi cho rằng cách nâng cấp an toàn nhất là khi quyết định nâng cấp được ủy quyền cho chính người dùng. Tương đương với nâng cấp do người dùng kiểm soát này như sau:
Giả sử người dùng đang sử dụng cầu kết nối để chuyển DAI giữa Ethereum và NEAR. Giả sử họ đã có x DAI được khóa trong TokenLocker và có x nearDAI ở bên phía NEAR.
Giả sử một ngày họ nhận được thông báo rằng NEAR hoặc Ethereum đang thực hiện thay đổi giao thức và họ cần di chuyển đến cầu kết nối v2 trong vòng một tuần.
Họ chuyển nearDAI trở lại DAI bằng cách sử dụng cầu kết nối cũ, sau đó chuyển DAI vào nearDAI v2 bằng cách sử dụng cầu kết nối v2.
Tuy nhiên cách này có mặt bất lợi:
Không giống như hợp đồng bình thường, cầu kết nối là một hệ thống phức tạp đòi hỏi sự bảo trì và cần ai đó cần chạy các Relays (rơ le) một cách liên tục, nếu không các light client sẽ đi ra khỏi sự đồng bộ với các blockchains và trở nên vô dụng. Điều đó có nghĩa là chúng ta không thể yêu cầu người dùng tự di chuyển từ cầu kết nối v1 đến cầu kết nối v2 khi có thể. Nếu chúng ta tắt các relays (rơ le) của cầu kết nối v1 trước khi mọi người chuyển tài sản của họ ra ngoài, tài sản của họ có thể vĩnh viễn bị khóa mà không có khả năng chuyển sang cầu kết nối v2. Nếu chúng ta chạy relay (rơ le)quá dài và chờ cho đến khi mỗi người sử dụng để di chuyển thì chúng tôi sẽ phải gánh chi phí gas hàng ngày và nó xấp xỉ 40 USD/ngày ở giá 40gwei.
Các ứng dụng tích hợp với cầu kết nối của chúng tôi sẽ cần phải biết về việc di chuyển vì chúng sẽ cần chuyển từ hợp đồng MintableFungibleToken cũ sang hợp đồng MintableFungibleToken mới. Một số người trong số họ có thể cần phải tự thực hiện quá trình di chuyển này hoặc hướng dẫn người dùng thực hiện bằng giao diện người dùng.
Do những nhược điểm trên, chúng tôi đã quyết định triển khai tùy chọn khả năng nâng cấp sau vào cầu kết nối của mình. Chúng tôi sẽ sử dụng một trong các mẫu proxy để cho phép EthOnNearClient, EthOnNearProver, NearOnEthClient và NearOnEthProver tự động chuyển sang các phiên bản hợp đồng mới khi họ nhận được bằng chứng rằng 2/3 cổ phần NEAR đã bỏ phiếu cho một hợp đồng mới. TokenLocker và MintableFungibleToken sẽ không cần phải thay đổi, trong hầu hết nếu không phải là tất cả các trường hợp và do đó việc nâng cấp sẽ minh bạch với người dùng và nhà phát triển ứng dụng. Điều này sẽ không ảnh hưởng đến mô hình tin cậy của cầu kết nối vì dù sao chúng ta cũng cần tin tưởng 2/3 số tiền NEAR Stake. Chúng tôi sẽ sử dụng cùng một hợp đồng bình chọn cho các cơ chế quản trị khác tại NEAR. Chúng tôi cũng sẽ cố gắng giảm thiểu khả năng cơ chế này được sử dụng làm cửa sau bằng cách tạo ra thời gian trì hoãn 7 ngày khi nâng cấp để người dùng có thể quan sát, xác minh và nếu họ không thích, hãy thanh lý mã thông báo của họ hoặc di chuyển chúng đến một cầu kết nối khác theo cách thủ công. Tuy nhiên, chúng tôi sẽ để lại khả năng cho những người xác thực NEAR bình chọn cho một bản nâng cấp khẩn, nhưng chúng tôi không mong đợi sẽ thực hiện nó.
Ưu đãi
Rainbow Bridge hiện tại không thực hiện ưu đãi cho những người bảo trì mà họ trả tiền gas bằng việc chuyển tiếp các header. Người sử dụng chính của cầu kết nối được kỳ vọng là họ sẽ tự chạy relay (rơ le) riêng của họ và có ít nhất một cặp relay (rơ le) được vận hành bởi NEAR collective. Các phiên bản tương lai của cầu kết nối sẽ có một lựa chọn để bắt người thực hiện việc chuyển tiền sẽ phải trả phí cho việc sử dụng gas trong việc chuyển, mã thông báo gốc gốc hoặc một số việc khác. Tuy nhiên để thiết kế một hệ thống ưu đãi thì khá là khó khăn. Cách tiếp cận đơn giản nhất sẽ tích lũy thuế từ người sử dụng trong cầu kết nối và phân phối nó cho các nhà bảo trì là những người chạy relay (rơ le). Thật không may, một hệ thống như vậy không tránh khỏi các trục trặc ngoài mong muốn, ví dụ: khi cầu kết nối gặp trục trặc khiến người dùng ngừng sử dụng trong một thời gian và do đó làm cho người bảo trì không còn hứng thú trong việc chay relay (rơ le). Đội ngũ của chúng tôi đang dành thời gian để phát triển một hệ thống khuyến khích cho người dùng, trước tiên chúng tôi sẽ duy trì nó bằng chi phí của mình.
Tham gia và trải nghiệm
Chúng tôi đã chạy Rainbow Bridge giữa Ropsten và NEAR Testnet trong vài tuần nay, nhưng chúng tôi chưa mở nó để ra mắt cho cộng đồng. Tuy nhiên, bạn có thể trải nghiệm khả năng chuyển giao của cầu kết nối bằng cách chạy một NEAR Node và Ganache nội bộ. Xin hãy chắc chắn rằng bạn đã cài đặt tất cả ứng dụng liên quan trước, vì là số khá rộng: Rust + Wasm, Golang, pm2, node <=13. Chúng tôi đang làm việc để gỡ bỏ một số phụ thuộc này.
Nếu bạn là nhà phát triển hoặc nhà thiết kế, cùng chúng tôi tham gia chương trình hack the Rainbow ? sẽ mở online vào ngày 15 đến ngày 30/12/2020. Bạn cũng có thể tham gia vào Bridge Guild của chúng tôi nơi chúng tôi sẽ thảo luận về các tích hợp khác nhau, các ứng dụng thực tiễn mới và xây dựng các dự án mà nó sử dụng cầu kết nối. Vui lòng theo dõi blog của chúng tôi để cập nhật những thông tin mới nhất.
Các light client
Đây là sơ đồ đơn giản của các light client hoạt động trong cầu kết nối:
Lưu ý, ngoài các hợp đồng thông minh mà triển khai các light client thì chúng tôi còn có hai dịch vụ khác, được gọi là Relay (rơ-le), thường gửi các header cho các light client. Eth2NearRelay gửi mỗi header cho hợp đồng EthOnNearClient, trong khi Near2EthRelay gửi một header mỗi 4 giờ vào hợp đồng EthOnNearClient. Đối với cặp hợp đồng EthOnNearClient và NearOnEthClient thì có thể có một số cặp dịch vụ Eth2NearRelay và Near2EthRelay. Mỗi người bảo trì của cầu kết nối có thể chạy các cặp dịch vụ của họ. Các cặp dịch vụ này có thể cạnh tranh với nhau, chúng sẽ cố gửi các khối giống nhau cùng một lúc và chỉ có một thành công mỗi lần hoặc sao lưu lẫn nhau, một số dịch vụ sẽ chỉ gửi khối nếu các khối khác không gửi trong thời gian quy định. Việc thực hiện các dịch vụ hiện tại của chúng tôi chạy ở chế độ đầu tiên.
EthOnNearClient
Như chúng tôi đã chia sẽ về EthOnNearClient, nó là một phiên thực hiện của light client Ethereum trong Rust như là một hợp đồng NEAR. Nó chấp nhận các Eethereum header và duy trì chuỗi canonical, nó giả định rằng các khối có đặc điểm finalized_gc_threshold không thể rời khỏi chuỗi canonical, và nó ghi nhớ hashes_gc_threshold của các khối từ chuỗi canonical, nơi hashes_gc_threshold >= finalized_gc_threshold. Giá trị mặc định của finalized_gc_threshold = 46k mà nó tương ứng khoảng 7 ngày giá trị của các header. Điều này được thực hiện để trạng thái của EthOnNearClient không phát triển đến vô tận. Hãy nhớ rằng điều này trong NEAR là yêu cầu có một số mã thông báo bị khóa nhất định để có thể sử dụng được trạng thái đó (xem thêm tại đây), và nó sẽ yêu cầu một lượng lớn và ngày càng tăng lượng khóa mã thông báo nếu chúng ta lưu trữ các hash của mỗi khối Ethereum canonical header trong một hợp đồng duy nhất. Do đó chúng tôi lưu trữ một số giới hạn hash của Ethereum header. Một kết quả của cầu kết nối chỉ có thể được sử dụng để chứng minh sự kiện đã xảy ra trong thời gian này. Vì vậy, nếu bạn bắt đầu chuyển ERC20 từ Ethereum đến NEAR, hãy đảm bảo hoàn thành trong vòng 7 ngày nếu nó bị gián đoạn giữa chừng.
Một sắc thái quan trọng khác của EthOnNearClient là cách nó xác minh Ethereum header. Nó sẽ không thể xác minh Ethereum Pow trực tiếp trong hợp đồng vì nó sẽ yêu cầu lưu trữ các tập tin DAG của Ethereum, thứ mà sẽ yêu cầu sử dụng bộ nhớ cấm. Tháng 5 mắn thay, mỗi khối Ethereum chỉ sử dụng một tập hợp con của các yếu tố từ tập tin DAG, và chỉ có một tập tin DAG cho mỗi Ethereum epoch. Hơn nữa, tập tin DAG có thể được tính toán trước cho các epoch tương lai. Chúng tôi tính toán trước tập tin DAG cho khoảng 4 năm và hợp nhất chúng. Hợp đồng EthOnNearClient sau đó ghi nhớ các merkle gốc của các tập tin DAG cho 4 năm tiếp theo sau khi khởi tạo. EthOnNearClient sau đó chỉ cần nhận được các Ethereum header, các yếu tố DAG và các bằng chứng merkle của các yếu tố này, cho phép nó xác minh Pow mà không cần toàn bộ tập tin DAG trong bộ nhớ. Chúng tôi đã tiếp cận phương pháp này từ EOS Bridge được sử dụng bởi Kyber network, và chúng tôi thậm chí tái sử dụng một số mã của họ. Tháng 5 mắn thay, việc xác minh của Ethereum header chỉ sử dụng 1/3 trong giới hạn tối đa của gas giao dịch và 1/10 của giới hạn gas của khối.
NearOnEthClient
NearOnEthClient là một phiên thực hiện của khối NEAR light client trong Solidity như một hợp đồng Eethereum. Không giống như EthOnNearClient nó không cần phải xác minh mỗi khối NEAR header và có thể bỏ qua hầu hết chúng miễn là nó kiểm tra ít nhất một header trong một NEAR epoch, nó có khoảng 43k khối và kéo dài khoảng nửa ngày. Kết quả là EthOnNearClient có thể ghi nhớ hash của tất cả các khối NEAR header đã gửi trong lịch sử, vì vậy nếu bạn đang thực hiện một phiên chuyển từ NEAR đến Ethereum nhưng nó bị gián đoạn , bạn không cần phải lo lắng nhiều, bạn có thể tiếp tục nó bất cứ lúc nào và thậm chí cả tháng sau đó cũng được. Một thuộc tính hữu ích của NEAR light client là tất cả NEAR header chứa một merkle gốc tính từ tất cả các khối header trước nó. Kết quả là nếu bạn có một NEAR header, bạn có thể xác minh hiệu quả bất kỳ sự kiện xảy ra trong bất kỳ header trước nó.
Một thuộc tính hữu ích khác của NEAR light client là nó chỉ chấp nhận các khối đã hoàn thành và các khối cuối không thể rời khỏi chuỗi canonical trong NEAR. Điều này có nghĩa là NearOnEthClient không cần lo lắng về việc fork.
Tuy nhiên, NEAR sử dụng ED25519 để ký thông báo của các Validators người mà sẽ xác nhận các khối và chữ ký này không có sẵn như là một biên dịch EVM. Nó làm cho sự xác minh của tất cả các chữ ký của một NEAR header trở nên tốn kém. Vì vậy, về mặt kỹ thuật chúng tôi không thể xác minh một NEAR header trong một lệnh gọi hợp đồng đến NearOnEthClient. Do đó chúng tôi áp dụng phương pháp optimistic nơi mà NearOnEthClient kiểm tra tất cả mọi thứ trong NEAR header ngoại trừ chữ ký. Sau đó bất cứ ai có thể thử thách một chữ ký trong một header đã gửi trong một cửa sổ 4 giờ thách thức. Thử thách yêu cầu xác minh của một chữ ký Ed25519 duy nhất mà có chi phí khoảng 500k ethereum gas (vô cùng tốn kém, nhưng có thể). Người dùng gửi NEAR header phải đăng một trái phiếu bằng mã thông báo Ethereum và một thử thách thành công phải đốt một nửa trái phiếu đã đăng và trả lại một nửa kia cho người thách thức. Khoản trái phiếu phải đủ lớn để trả phí gas thậm chí là nếu giá gas tăng theo cấp số nhân trong 4 giờ. Ví dụ, một trái phiếu là 20 eth sẽ phải chi trả giá gas tăng lên đến 20000 gwei. Phương pháp này đòi hỏi phải có một dịch vụ Watchdog để giám sát các NEAR header đã gửi và thách thức bất kỳ header với chữ ký không hợp lệ. Đối với bảo mật bổ sung, người dùng độc lập có thể chạy một số dịch vụ Watchdog.
Một khi EIP665 được chấp nhận, Ethereum sẽ có chữ ký Ed25519 có sẵn như là biên dịch EVM. Điều này sẽ làm cho dịch vụ giám sát và việc thách thức trong 4 giờ trở nên không cần thiết.
Ở mức tối thiểu, Rainbow Bridge bao gồm các hợp đồng EthOnNearClient và NearOnEthClient và ba dịch vụ: Eth2NearRelay, Near2EthRelay và Watchdog. Chúng tôi có thể tranh luận rằng điều này đã tạo thành một cầu nối vì chúng tôi đã thiết lập một liên kết mật mã giữa hai blockchain, nhưng thực tế nó yêu cầu một phần lớn mã bổ sung để khiến các nhà phát triển ứng dụng thậm chí cân nhắc sử dụng Rainbow Bridge cho các ứng dụng của họ.
Provers
Điều mà có thể làm cho các client hữu ích hơn là khả năng chứng minh rằng điều gì đó đã xảy ra cụ thể trên một blockchain. Để làm được điều đó, chúng tôi thực hiện hợp đồng NEAR EthOnNearProver trong Rust và hợp đồng Ethereum NearOnEthProver trong Solidity. EthOnNearProver có thể xác minh các sự kiện Ethereum, trong khi hợp đồng NearOnEthProver có thể xác minh kết quả thực hiện của hợp đồng NEAR. Cả hai hợp đồng EthOnNearProver và NearOnEthProver được thực hiện riêng biệt từ EthOnNearClient và NearOnEthClient vì nhiều lý do:
Hiện tại, chúng tôi chỉ có các sự triển khai chỉ để xác minh các sự kiện Ethereum và kết quả thực hiện hợp đồng NEAR, chúng đủ để di chuyển mã thông báo giữa các blockchain. Nhưng bất cứ ai cũng được hoan nghênh để đóng góp vào sự triển khai của prover.
(Một EthOnNearClient có thể có nhiều provers giao tiếp với nó sao chép trên nhiều shards, trong khi NearOnEthClient sẽ có một bản sao duy nhất của từng loại của các provers giao tiếp tiếp với nó).
Trường hợp sử dụng ERC20
Các provers cho phép chúng tôi xây dựng một bộ hợp đồng cho phép chuyển giao tài sản hoặc giao tiếp chuỗi chéo. Tuy nhiên, các hợp đồng này sẽ rất khác nhau tùy thuộc vào chính xác chúng tôi muốn tương tác trên cầu kết nối. Ví dụ: ERC20 yêu cầu một bộ hợp đồng hoàn toàn riêng biệt từ ERC721 hoặc chuyển mã thông báo gốc. Hiện tại, Rainbow Bridge có sự hỗ trợ ngoại vi cho chuyển mã thông báo ERC20 riêng biệt và chúng tôi sẽ thêm nhiều trường hợp sử dụng trong tương lai. Trong bài này, chúng tôi chỉ tập trung vào các trường hợp sử dụng ERC20.
Giả sử có một mã thông báo ERC20 tồn tại trên Ethereum, ví dụ DAI. Để chúng ta di chuyển chúng qua cầu kết nối thì chúng tôi cần triển khai hai hợp đồng bổ sung:
Khi người dùng muốn chuyển X lượng DAI từ Ethereum sang NEAR, trước tiên họ khóa X DAI này trong hợp đồng TokenLocker, sau đó mint x nearDAI trong hợp đồng MintableFungibleToken NEAR. Khi họ muốn chuyển một số mã thông báo trở lại từ NEAR sang Ethereum, trước tiên họ đốt Y nearDAI trong MintableFungibleToken và sau đó mở khóa Y DAI trong TokenLocker.
Hiện tại, mỗi phiên của mã thông báo ERC20 sẽ yêu cầu triển khai một cặp TokenLocker/MintableFungibleToken riêng biệt; Tuy nhiên, chúng tôi sẽ gỡ bỏ hạn chế này trong tương lai và sử dụng cùng một TokenLocker cho nhiều mã thông báo ERC20. Lưu ý rằng nếu ai đó muốn thêm hỗ trợ ERC721 hoặc một loại chuyển tài sản khác, họ sẽ cần triển khai cặp Locker/Asset tương tự với giao diện bên ngoài và triển khai nội bộ khác, nhưng thiết kế cấp cao sẽ vẫn như cũ – Locker sẽ khóa/mở khóa tài sản trong khi tài sản sẽ mint/hủy phiên bản NEAR nhất của tài sản này.
Lưu lượng sử dụng
Người dùng sẽ có thể sử dụng RainbowCLI hoặc bất kỳ ứng dụng nào tích hợp với RainbowLib, giống như ví NEAR . Trong trường hợp hiếm hoi, người nào đó có thể chọn làm việc với cầu kết nối thủ công bằng cách gọi các hợp đồng Ethereum và NEAR từ lớp hợp đồng cấp thấp. Hiện tại, chúng tôi chỉ hỗ trợ RainbowCLI, nhưng chúng tôi đang làm việc trên RainbowLib và ví tích hợp.
Từ góc độ người dùng, việc chuyển mã thông báo phải đơn giản: họ cung cấp thông tin đăng nhập, chọn người nhận và số tiền, đồng thời bắt đầu chuyển từ RainbowCLI, Ví hoặc các ứng dụng khác. Sau một thời gian, quá trình chuyển thành công và người dùng nhận được xác nhận. Tuy nhiên, đằng sau quá trình đơn giản đó, RainbowLib sẽ thực hiện các thao tác phức tạp sau:
Tương tự, RainbowLib sẽ có thể thực hiện chuyển các mã thông báo không phải ERC20 và thực hiện gọi các gọi hợp đồng.
Hard forks
Chúng tôi muốn Rainbow Bridge hiện tại không bị phá vỡ khi sự thay đổi giao thức NEAR hoặc Ethereum đang diễn ra. Và chúng tôi muốn có thể nâng cấp các hợp đồng cầu nối khi có các bản nâng cấp về hiệu năng, ví dụ: nếu EIP665 được chấp nhận. Tuy nhiên, chúng tôi không muốn nó trở nên kém tin cậy hoặc phi tập trung hơn bằng cách giới thiệu một cách tập trung vào giai đoạn ban đầu của sự nâng cấp.
Có rất nhiều mẫu proxy được phát triển bởi cộng đồng Ethereum cho phép cập nhật hợp đồng. Tuy nhiên, chúng tôi cho rằng cách nâng cấp an toàn nhất là khi quyết định nâng cấp được ủy quyền cho chính người dùng. Tương đương với nâng cấp do người dùng kiểm soát này như sau:
Tuy nhiên cách này có mặt bất lợi:
Do những nhược điểm trên, chúng tôi đã quyết định triển khai tùy chọn khả năng nâng cấp sau vào cầu kết nối của mình. Chúng tôi sẽ sử dụng một trong các mẫu proxy để cho phép EthOnNearClient, EthOnNearProver, NearOnEthClient và NearOnEthProver tự động chuyển sang các phiên bản hợp đồng mới khi họ nhận được bằng chứng rằng 2/3 cổ phần NEAR đã bỏ phiếu cho một hợp đồng mới. TokenLocker và MintableFungibleToken sẽ không cần phải thay đổi, trong hầu hết nếu không phải là tất cả các trường hợp và do đó việc nâng cấp sẽ minh bạch với người dùng và nhà phát triển ứng dụng. Điều này sẽ không ảnh hưởng đến mô hình tin cậy của cầu kết nối vì dù sao chúng ta cũng cần tin tưởng 2/3 số tiền NEAR Stake. Chúng tôi sẽ sử dụng cùng một hợp đồng bình chọn cho các cơ chế quản trị khác tại NEAR. Chúng tôi cũng sẽ cố gắng giảm thiểu khả năng cơ chế này được sử dụng làm cửa sau bằng cách tạo ra thời gian trì hoãn 7 ngày khi nâng cấp để người dùng có thể quan sát, xác minh và nếu họ không thích, hãy thanh lý mã thông báo của họ hoặc di chuyển chúng đến một cầu kết nối khác theo cách thủ công. Tuy nhiên, chúng tôi sẽ để lại khả năng cho những người xác thực NEAR bình chọn cho một bản nâng cấp khẩn, nhưng chúng tôi không mong đợi sẽ thực hiện nó.
Ưu đãi
Rainbow Bridge hiện tại không thực hiện ưu đãi cho những người bảo trì mà họ trả tiền gas bằng việc chuyển tiếp các header. Người sử dụng chính của cầu kết nối được kỳ vọng là họ sẽ tự chạy relay (rơ le) riêng của họ và có ít nhất một cặp relay (rơ le) được vận hành bởi NEAR collective. Các phiên bản tương lai của cầu kết nối sẽ có một lựa chọn để bắt người thực hiện việc chuyển tiền sẽ phải trả phí cho việc sử dụng gas trong việc chuyển, mã thông báo gốc gốc hoặc một số việc khác. Tuy nhiên để thiết kế một hệ thống ưu đãi thì khá là khó khăn. Cách tiếp cận đơn giản nhất sẽ tích lũy thuế từ người sử dụng trong cầu kết nối và phân phối nó cho các nhà bảo trì là những người chạy relay (rơ le). Thật không may, một hệ thống như vậy không tránh khỏi các trục trặc ngoài mong muốn, ví dụ: khi cầu kết nối gặp trục trặc khiến người dùng ngừng sử dụng trong một thời gian và do đó làm cho người bảo trì không còn hứng thú trong việc chay relay (rơ le). Đội ngũ của chúng tôi đang dành thời gian để phát triển một hệ thống khuyến khích cho người dùng, trước tiên chúng tôi sẽ duy trì nó bằng chi phí của mình.
Tham gia và trải nghiệm
Chúng tôi đã chạy Rainbow Bridge giữa Ropsten và NEAR Testnet trong vài tuần nay, nhưng chúng tôi chưa mở nó để ra mắt cho cộng đồng. Tuy nhiên, bạn có thể trải nghiệm khả năng chuyển giao của cầu kết nối bằng cách chạy một NEAR Node và Ganache nội bộ. Xin hãy chắc chắn rằng bạn đã cài đặt tất cả ứng dụng liên quan trước, vì là số khá rộng: Rust + Wasm, Golang, pm2, node <=13. Chúng tôi đang làm việc để gỡ bỏ một số phụ thuộc này.
Nếu bạn là nhà phát triển hoặc nhà thiết kế, cùng chúng tôi tham gia chương trình hack the Rainbow ? sẽ mở online vào ngày 15 đến ngày 30/12/2020. Bạn cũng có thể tham gia vào Bridge Guild của chúng tôi nơi chúng tôi sẽ thảo luận về các tích hợp khác nhau, các ứng dụng thực tiễn mới và xây dựng các dự án mà nó sử dụng cầu kết nối. Vui lòng theo dõi blog của chúng tôi để cập nhật những thông tin mới nhất.