Bài viết này thảo luận về việc bắt đầu với nền tảng và động lực đằng sau thiết kế của cầu nối Namada Ethereum, tiếp theo là cách thức hoạt động của cầu nối và kết thúc bằng kiến trúc hợp đồng thông minh.
Namada blockchain nhắm đến việc cung cấp một bộ quyền riêng tư thống nhất cho càng nhiều tài sản càng tốt, vì quyền riêng tư có tính chất bổ sung. Như vậy, khả năng tương tác là một thành phần thiết yếu của Namada. Ngoài việc triển khai giao thức IBC, Namada sẽ có cầu nối tích hợp với Ethereum.
Trong bài đăng trên blog này, chúng tôi sẽ thảo luận về thiết kế và tính năng của cầu nối này. Chúng tôi sẽ chia thiết kế thành ba phần. Trong phần đầu tiên, chúng tôi sẽ giải thích lý do tại sao chúng tôi quyết định xây dựng một cầu nối chuyên dụng và cách thiết kế cầu nối hoạt động cơ bản. Trong phần thứ hai, chúng tôi cung cấp thông tin chi tiết về cách chuyển tiếp tài sản từ Ethereum sang Namada và ngược lại từ Namada sang Ethereum. Trong phần thứ ba, chúng ta sẽ thảo luận về kiến trúc hợp đồng thông minh.
Mọi phản hồi, thắc mắc hoặc thảo luận về bài viết này, vui lòng truy cập chủ đề này trên diễn đàn Namada (https://forum.namada.net/t/the-namada-ethereum-bridge-article-discussions/101)
Tích hợp trực tiếp vào Namada
Cầu Ethereum được tích hợp trực tiếp vào Namada thay vì là một giao thức độc lập. Các validators (Validators) của Namada chạy cầu nối như một phần cốt lõi của giao thức Namada . Để chuyển tài sản sang Namada, trình xác thực cũng đóng vai trò là người chuyển tiếp; không cần tác nhân nào khác. Tuy nhiên, để chuyển giao tài sản sang Ethereum, các tác nhân bên thứ ba (relayers) sẽ tham gia, nhưng họ không chịu trách nhiệm về bất kỳ xác nhận hoặc bảo mật nào của cầu nối
Điều này có nghĩa là tính tồn tại và tính bảo mật của cầu Ethereum gắn trực tiếp với tính tồn tại và bảo mật của toàn bộ Namada. Nói chung, khi chuyển tài sản qua cầu nối sang các chuỗi khác, người dùng phải tin tưởng cả validators của cầu cũng như các validators của chuỗi đích. Vì người dùng phải tin tưởng các validators của Namada để sử dụng Namada bằng mọi cách nên việc tích hợp cầu nối theo cách này không bổ sung thêm bất kỳ giả định bảo mật nào. Do đó tính bảo mật của tài sản của họ không thực sự an toàn. Có các thiết kế cầu nối vững chắc tương thích với IBC khác như của Gravity và Axelar. Và hơn hết Namada cũng có thể kết nối và hỗ trợ những cầu nối đó, nhưng chúng yêu cầu người dùng chấp nhận các giả định bảo mật bổ sung (và một số độ trễ).
Validators của Namada sẽ chạy các nút đầy đủ của Ethereum và giám sát các sự kiện diễn ra từ các hợp đồng thông minh cầu nối được triển khai trên Ethereum. Các sự kiện từ hợp đồng thông minh được kích hoạt bởi nhiều giao dịch khác nhau như di chuyển mã thông báo qua lại cầu nối, cũng như một số mục đích quản trị. Validators của Namada sẽ đợi cho đến khi giao dịch kích hoạt được hoàn tất và sau đó chia sẻ với những validators khác rằng họ đã thấy một sự kiện nhất định được phát ra từ Ethereum.
Khi bỏ phiếu trên một khối Namada mới, người xác nhận phải bao gồm danh sách có chữ ký của các sự kiện mới mà họ coi là một phần trong phiếu bầu của mình. Khi 2/3 phần lớn validtators đã bỏ phiếu cho một sự kiện cụ thể, điều đó được coi là sự thật và blockchain Namada có thể hành động theo nó. Người xác nhận chỉ nên bỏ phiếu cho các sự kiện khó có thể đảo ngược và thay đổi (theo nghĩa Ethereum 1 PoW) hoặc đã được hoàn thiện (theo nghĩa Ethereum 2 PoS).
Trong Ethereum 2 (hiện tại), để xác định tính hợp lý của một sự kiện, chúng ta cần có ít nhất 2/3 sức mạnh đặt cược tham gia bỏ phiếu cho sự kiện đó “hai lần” và ở những giai đoạn khác nhau. Cụ thể hơn, block đầu tiên trong mỗi giai đoạn có thể được coi là hợp lý khi nó đã được bỏ phiếu trong hai cặp độc lập (nhưng có liên quan đến nhau). Cặp đầu tiên cho phép khối được “bảo vệ”, và cặp thứ hai cho phép nó được xác nhận là hợp lý. Do đó, quá trình xác định tính hợp lý xảy ra sau hơn so với Namada
Các sự kiện sẽ ít có khả năng bị đảo ngược nếu khối chứa nó có đủ nhiều “confirmations”, tức là các khối kế tiếp đã được xác nhận. Số lượng confirmations cần thiết để coi một sự kiện là “cuối cùng” được thiết lập từ đầu trong Namada, nhưng có thể thay đổi thông qua quy trình quản trị. Trong Ethereum 2, khi một khối đạt được 64 confirmations, nó sẽ thuộc về hoặc là tổ tiên của một khối checkpoint cuối cùng. Điều này có nghĩa là để một khối khác cùng độ cao được xác nhận bởi một quorum của các validator Ethereum, ít nhất một phần ba tổng số cược của các validator có thể mất. Do đó, có thể xem xét rằng 64 confirmations là đủ trong Ethereum 2
Điều đáng lưu ý là bất kỳ validators nào cũng có thể gửi một sự kiện giả mạo, nhưng nó sẽ không tích lũy đủ số phiếu ủng hộ để thực hiện trừ khi toàn bộ bảo mật của Namada bị xâm phạm. Nếu validators Namada muốn xác minh rằng các sự kiện là xác thực, điều này sẽ yêu cầu cung cấp light client proofs chứng thực việc đưa một giao dịch vào Ethereum tạo ra một sự kiện nhất định. Điều này sẽ yêu cầu trình xác thực Namada chạy ứng dụng Ethereum light clients để xác minh bằng chứng đó. Cho phép các sự kiện giả có nghĩa là trình xác thực Namada không cần chạy Ethereum light clients để xác minh rằng các sự kiện là có thật. Điều này giúp đơn giản hóa đáng kể quá trình kết nối và không ảnh hưởng đáng kể đến các giả định về bảo mật của chúng tôi (vì dù sao thì 2/3 quyền biểu quyết cũng có thể ký các khối tùy ý).
Chuyển tài sản đến Namada
Vì chuỗi Namada hoạt động như một nguồn thông tin cho các hợp đồng Ethereum liên quan, quá trình chuyển tài sản từ Ethereum đến Namada cho người dùng rất thuận lợi. Chỉ cần gửi giao dịch liên quan đến các hợp đồng cầu nối sẽ tạo ra một sự kiện. Sự kiện này sẽ được quan sát và bỏ phiếu bởi các validator Namada. Khi nó có đủ phiếu hậu thuẫn, việc phát hành tài sản đến một địa chỉ Namada sẽ tự động và miễn phí. Việc thanh toán phí gas trên Ethereum đủ để ngăn chặn mọi mối đe dọa từ các vector tấn công từ chối dịch vụ.
Chuyển tài sản trở lại Ethereum
Quá trình chuyển tài sản từ Namada trở lại Ethereum không đơn giản như việc ngược lại, vì Ethereum không chạy đầy đủ nút Namada. Điều này có nghĩa là giao dịch trên Namada khởi tạo chuyển tới Ethereum cần phải được chuyển tiếp đến hợp đồng thông minh liên quan.
Điều này đặt ra nhiều thách thức:
- Phải tạo một giao dịch Ethereum.
- Người nào đó phải gửi giao dịch này.
- Người nào đó phải thanh toán phí gas.
Việc gửi các giao dịch một cách đơn lẻ không hiệu quả về chi phí, cần phải sử dụng phương pháp gom nhóm (batching). Để giải quyết những vấn đề này, Namada sẽ duy trì một hồ bơi cầu nối Ethereum gồm các yêu cầu chuyển tài sản. Hồ bơi này nên được xem xét như một “mempool”. Khi một người dùng Namada thêm một yêu cầu chuyển vào hồ bơi, họ có thể chọn thanh toán một số lượng NAM (hoặc một tài sản khác được phê duyệt) như một khoản phí. Khoản phí này được giữ bởi Namada.
Bất kỳ ai cũng có thể chọn chuyển tiếp một phần yêu cầu chuyển trong hồ bơi bất cứ lúc nào. Hồ bơi cầu nối Ethereum được tổ chức dưới dạng cây Merkle và root mới nhất được ký bởi các validator. Chuyển tiếp yêu cầu chuyển đòi hỏi việc gửi các chuyển tới hợp đồng thông minh Ethereum liên quan cùng với một bằng chứng Merkle về các chuyển và root của cây Merkle được ký bởi một quorum của các validator Namada.
Giao dịch như vậy sẽ phát ra một sự kiện được quan sát bởi các validator Namada. Khi nó được xác nhận trên chuỗi, các khoản phí đặt cọc cho các chuyển sẽ được cấp cho người chuyển tiếp chúng.
Lưu ý rằng bằng cách sử dụng cây Merkle, bất kỳ tập con nào của hồ bơi cầu nối cũng có thể được chuyển tiếp theo bất kỳ thứ tự nào. Điều này ngăn chặn các cuộc tấn công nơi lượng lớn các giao dịch nhỏ được gửi qua cầu nối để làm chậm nó. Tuy nhiên, mỗi lô chuyển tiếp sẽ được đặt một số thứ tự để ngăn chặn việc chuyển tiếp các chuyển.
Thiết kế này tránh được sự cần thiết của các oracles gas Ethereum vì động cơ thị trường sẽ thúc đẩy người dùng xác định phí phù hợp và xem xét yêu cầu chuyển nào là kinh tế nhất để chuyển tiếp. Nếu phí cho yêu cầu chuyển quá thấp, cuối cùng yêu cầu đó sẽ “hết thời gian” và bị loại khỏi hồ bơi và tất cả các tài sản đặt cọc sẽ được trả lại. Thời gian chờ này là một tham số giao thức được đặt từ genesis và có thể được thay đổi thông qua quản trị Namada.
Chứng minh trên Ethereum
Chúng ta đã nói trước đó rằng chúng ta cần gửi một Merkle root được ký đến các hợp đồng Ethereum liên quan để chuyển tiếp yêu cầu chuyển. Thực tế, bất kỳ giao dịch nào được ký bởi một quorum của các validators nên được chấp nhận bởi các hợp đồng thông minh Ethereum, vì chúng bản chất là chứng minh lightclient của Namada.
Để làm cho chứng minh như vậy hiệu quả về gas, chứng minh phải sử dụng băm Keccak và định dạng serialization ABI của Ethereum. Validators Namada cũng phải có tài khoản trên Ethereum để họ có thể ký.
Do bộ validators trên Namada có thể thay đổi mỗi epoch, các hợp đồng thông minh Ethereum cần một cách để biết phải kiểm tra chữ ký nào khi xác minh một chứng minh. Điều này đòi hỏi gửi một bản cập nhật bộ validators tới Ethereum mỗi epoch với các địa chỉ, public keys, và sức mạnh bỏ phiếu mới.
Bản cập nhật này phải được ký bởi ít nhất 2/3 số validators theo giá trị bỏ phiếu của epoch trước, ủy quyền cho bản cập nhật này bằng cách sử dụng khóa Ethereum của họ. Khi một epoch mới bắt đầu, bộ validators mới phải ký cho tập validators của epoch tiếp theo như một phần của phiếu bỏ phiếu cho một khối.
Phiếu của họ sẽ được ký bởi khóa Namada của họ và sẽ chứa tập validators mới được ký bởi khóa Ethereum của họ. Tập validators được chuyển theo chuỗi, vì vậy chúng ta biết về tập validators hai epochs trước. Điều này có nghĩa là “chuyển giao quyền lực” được liên kết với sự đồng thuận và sẵn có ở cuối mỗi epoch.
Khi một epoch mới bắt đầu, người lãnh đạo được chọn cho khối đầu tiên trong epoch này phải gửi bản cập nhật bộ validators như một giao dịch đến Ethereum, điều này sẽ tạo ra một sự kiện. Khi sự kiện này được xác nhận trên Namada, người lãnh đạo này sẽ nhận được phần thưởng cung tiến để bù đắp cho họ.
Không có cơ chế để trừng phạt người lãnh đạo nếu họ không thành công khi gửi bản cập nhật bộ validators. Vì bản cập nhật đã được ký và công khai trên chuỗi, bất kỳ ai cũng có thể gửi bản cập nhật đó đến hợp đồng Ethereum nếu cần thiết. Do đó, thiết kế này không tạo ra một lỗ hổng tấn công và phần thưởng tài chính nên đủ khuyến khích người lãnh đạo được chọn chuyển tiếp bản cập nhật bộ validators.
Các hợp đồng thông minh
Kiến trúc
Nhiều hợp đồng thông minh sẽ được triển khai trên Ethereum mainnet như một phần của cầu nối. Các hợp đồng chính mà người dùng sẽ tương tác là Hợp đồng Cầu nối và Hợp đồng wNAM. Hợp đồng Cầu nối được sử dụng để gửi hoặc nhận tài sản từ Namada. Hợp đồng wNAM là một token ERC20 đại diện cho NAM được bọc trên Ethereum. Lưu ý rằng chỉ có thể chuyển đổi các token ERC20 giữa Namada và Ethereum. Điều này có nghĩa là Ether không thể được chuyển đổi, nhưng Ether được bọc có thể (quá trình bọc có thể được tự động hóa thông qua giao diện).
Ngoài ra, còn ba hợp đồng khác: Hợp đồng Proxy, Governance, và Vault. Hợp đồng Proxy là một hợp đồng cố định giữ địa chỉ của tất cả các hợp đồng mới nhất. Điều này giúp nếu một hợp đồng được cập nhật, có một hợp đồng duy nhất để tra cứu và tìm địa chỉ mà hợp đồng đó được triển khai.
Hợp đồng Governance duy trì các tập validators cần thiết để xác minh các chứng minh. Nó cũng được sử dụng khi thay thế hợp đồng, tạm ngừng cầu nối, hoặc truy cập vào các khoản tiền bị khóa trong cầu nối khi cần thiết.
Hợp đồng Vault là một két và sổ cái của tất cả số dư token của tài sản trên cầu nối. Việc giữ nó như một hợp đồng riêng biệt giảm thiểu lượng lưu trữ cần phải di chuyển nếu Hợp đồng Cầu nối được cập nhật.
Bảo vệ đa tầng
Như chúng ta đã đề cập trước đó, validators của Namada phải có tài khoản Ethereum với public keys được cầu nối biết đến. Thực tế, validators cần phải có cả khóa nóng và khóa lạnh. Khóa nóng là những khóa được sử dụng thường xuyên, trong khi khóa lạnh nên được sử dụng ít thường xuyên vì chúng dành cho các hoạt động nhạy cảm. Cho đến giờ, khi nói về “khóa Ethereum”, chúng tôi đã đề cập đến khóa nóng.
Validators có thể sử dụng khóa lạnh của họ để khôi phục cầu nối trong các trường hợp cực kỳ khẩn cấp, chẳng hạn như sự cố về liveness. Một quorum của validators Namada có thể sử dụng khóa lạnh để rút tiền từ két được bảo đảm trong Vault đến bất kỳ địa chỉ Ethereum nào.
Những khóa này cũng được sử dụng cho quản lý của cầu nối, bao gồm nâng cấp lên các hợp đồng mới cũng như các khía cạnh quan trọng về an ninh như danh sách trắng token, giới hạn escrow, và giới hạn rút tiền.
Một danh sách trắng các token ERC20 được phép sẽ được duy trì bởi cầu nối. Hơn nữa, sẽ có một giới hạn về tổng số lượng của mỗi token mà cầu nối có thể giữ trong escrow. Điều này giới hạn thiệt hại có thể xảy ra từ cầu nối cũng như giảm giá trị của việc tấn công nó. Điểm quan trọng đặc biệt là quá mức đảm bảo cầu nối có thể làm mất hiệu lực các giả định an ninh của Namada. Điều này xảy ra khi giá trị trên cầu nối đủ lớn so với giá trị đã đặt cược bởi bất kỳ quorum nào của validators Namada.
Việc giới hạn token giúp đảm bảo rằng validators không đảm bảo giá trị nhiều hơn so với mức đã đặt cược. Một biện pháp giảm nhẹ khác là giới hạn tốc độ, nghĩa là một lượng tối đa của một token cụ thể có thể bị loại bỏ từ cầu nối mỗi epoch. Điều này làm chậm các cố gắng nhanh chóng di chuyển giá trị khỏi cầu nối trong trường hợp sự cố an toàn