Tiêu đề gốc: "IBC mô-đun cho thế giới mô-đun"
Tác giả gốc: Phòng thí nghiệm Polymer
Bản tổng hợp gốc: Kxp, BlockBeats

p>
Tính linh hoạt trong thiết kế của blockchain mô-đun và Rollup cũng giúp IBC có tính linh hoạt cao hơn. Cấu trúc liên kết mạng IBC đang thay đổi từ một mạng đồng nhất, được kết nối dày đặc sang một mạng không đồng nhất, được kết nối thưa thớt. IBC mô-đun sẽ cho phép giao thức IBC thích ứng với môi trường năng động này.
Trước đây, chúng ta đã nói về cách suy nghĩ về khả năng tương tác mô-đun. Hôm nay, chúng ta sẽ tìm hiểu sâu về cách blockchain mô-đun tác động đến thiết kế của lớp trạng thái IBC.
Hiện tại, trong mạng IBC, một client nhẹ Tendermint là đủ để đại diện cho một chuỗi khối logic vì tính đồng nhất của chính mạng. Tuy nhiên, các chuỗi khối mô-đun như Celestia phá vỡ tính đồng nhất này và chia chuỗi khối logic thành nhiều chuỗi. Do đó, bạn cần nhiều ứng dụng khách nhẹ để đại diện cho một chuỗi khối logic duy nhất và mỗi ứng dụng khách nhẹ có thể đại diện cho một lớp khác nhau của ngăn xếp chuỗi khối.

Trong một môi trường duy nhất, việc chạy một nút đầy đủ hoặc xác thực một bằng chứng đồng thuận duy nhất thường đủ để thuyết phục các bên thứ ba về việc chuyển đổi trạng thái. Trong môi trường mô-đun, chúng ta cần thu được nhiều bằng chứng khác nhau để xác nhận sự chuyển đổi trạng thái.
Chúng ta có thể phân loại các phương pháp xác minh khác nhau như sau:
· Bằng chứng trực tiếp (ví dụ: chạy một nút đầy đủ)
· Bằng chứng gian lận (ví dụ: Tổng hợp lạc quan)
· Bằng chứng hợp lệ hoặc không có kiến thức (ví dụ: zk Rollup)
· Bằng chứng về sự đồng thuận (ví dụ: khách hàng hạng nhẹ)
Chúng tôi có thể kết hợp các phương pháp xác minh ở trên với lớp tổng hợp của chuỗi khối để tự tin rằng chúng tôi đã thực hiện chuyển đổi trạng thái. Ví dụ: chúng tôi có thể thực hiện lấy mẫu dữ liệu sẵn có trực tiếp đối với Celestia. Ngoài ra, chúng tôi có thể chọn xác minh bằng chứng đồng thuận của Celestia.
Bất kể loại bằng chứng nào được sử dụng, logic light client (LC) đều mong muốn xác nhận những điều sau Ba điểm:
· Tính sẵn có của dữ liệu (DA)
· Trình tự hoặc lệnh giao dịch (TO)
· Thực thi
——Thanh toán
Để trưng bày Tính linh hoạt trong thiết kế, chúng ta sẽ khám phá nhiều thiết kế Tổng hợp khác nhau trên lớp sẵn có của dữ liệu chung:
· Thực thi + Bằng chứng gian lận==Lạc quan Tổng hợp
· Thực thi + Bằng chứng đồng thuận==Tổng hợp bi quan
· Thực thi + bằng chứng không có kiến thức==ZK Rollup
Trong một chuỗi khối duy nhất, Bảo mật chuỗi phụ thuộc vào điện toán khai thác sức mạnh của chuỗi PoW và cam kết Token của chuỗi PoS. Điều này có thể dẫn đến nhiều vấn đề bảo mật khác nhau khi khởi chạy chuỗi mới, chẳng hạn như vấn đề khởi động. Trong ngăn xếp chuỗi khối mô-đun, một chuỗi có thể lấy được bảo mật từ một hoặc nhiều nguồn bên ngoài.
Hiện tại có một số mô hình bảo mật dùng chung, một số mô hình tương thích trực tiếp với IBC, trong khi một số khác Cần có IBC mô-đun để hoạt động bình thường.
· Được thực hiện từ chuỗi sản xuất thông qua liên chuỗi bảo mật Bảo mật (ví dụ: Cosmos Hub)
——Phiên bản v1 của xác minh chuỗi chéo thay thế trình xác thực chuỗi tiêu dùng bằng trình xác thực chuỗi nhà sản xuất
· Đảm bảo bảo mật từ lớp thanh toán công khai (ví dụ: Ethereum)
· Kế thừa bảo mật từ lớp sẵn có của dữ liệu công cộng (ví dụ: Celestia, EigenDA)
- Lớp sẵn có của dữ liệu công khai có thể cung cấp khả năng chống kiểm duyệt để giảm thiểu sự tin cậy dựa trên bằng chứng gian lận Dữ liệu
· Nhận bảo mật từ nhà cung cấp bảo mật có thể lập trình (ví dụ: EigenLayer)
p>
——Các nhà cung cấp bảo mật có thể phải tuân theo các điều kiện cắt giảm bổ sung dựa trên những nỗ lực xác minh nhất định
·  ;Nhận bảo mật từ chuỗi sản xuất (ví dụ: Babylon) thông qua cơ chế điểm kiểm tra
- Cơ chế điểm kiểm tra có thể ngăn chặn các cuộc tấn công tầm xa và các cuộc tấn công liên kết yếu nhất (trong định tuyến IBC Multi-hop)
· Có được sự bảo mật thông qua việc đặt cược lại và đặt cược xuyên chuỗi (chẳng hạn như đặt cược thanh khoản, đặt cược siêu thanh khoản, v.v.)
——Hãy để số vốn cầm cố chịu các điều kiện phạt ở cấp độ người xác thực
Đối với kết nối EthereumL2 <> L2, chúng tôi cần nhiều đầu cuối client nhẹ để thể hiện mỗi logic chuỗi L2. Chúng ta có thể xem xét cụ thể tại Optimistic Rollup. Giữa các L2, bạn có thể tạo các đường hầm IBC với các thuộc tính bảo mật khác nhau. Lưu ý rằng ví dụ này giả định rằng chúng tôi đã chạy chuyển IBC trên chuỗi sau, mô hình chuyển IBC bằng Polymer là khác.
Độ trễ cao nhưng rủi ro thấp:
p>
· Một ứng dụng khách nhẹ của eth2 thực hiện các bằng chứng giải quyết và sẵn có của dữ liệu thay mặt cho Ethereum.
· Một khách hàng lạc quan với các quy tắc có điều kiện để thực hiện và bằng chứng đặt hàng giao dịch thay mặt cho Aribitrum hoặc Optimism.
- Quy tắc này sẽ đảm bảo rằng các khối Arbitrum hoặc Optimism được giải quyết và hoàn thiện trên Ethereum trước khi được chuyển sang các L2 khác.
Con đường có độ trễ thấp nhưng rủi ro cao:
p>
· Một máy độc lập, ủy ban hoặc khách hàng đồng thuận nhẹ chứng kiến các xác nhận mềm thay mặt cho bên thứ ba hoặc người sắp xếp thứ tự.
· Một khách hàng lạc quan với các quy tắc có điều kiện của Ethereum, thực hiện bằng chứng thực hiện và đặt hàng giao dịch thay mặt cho Arbitrum hoặc Optimism / p>

Lấy Celestia làm ví dụ, bạn cần nhiều ứng dụng khách nhẹ để thể hiện Optimistic Rollup hợp lý. Celestia cung cấp bằng chứng về sự đồng thuận làm bằng chứng về tính sẵn có của dữ liệu và thứ tự giao dịch.
Chúng ta có thể thấy IBC mô-đun đang hoạt động trên chuỗi IBC được kết nối với Celestia Rollup:
· Một ứng dụng khách Tendermint light (TMLC), Bằng chứng về tính sẵn có của dữ liệu và đặt hàng giao dịch thay mặt cho Celestia.
· Một ứng dụng khách Optimistic light với các quy tắc có điều kiện của Celestia, thực hiện bằng chứng thực thi thay mặt cho Optimistic Rollup.
- Quy tắc này sẽ đảm bảo rằng một khối có sẵn trên mạng Celestia trước khi một khối được hoàn tất.
Xin lưu ý rằng một số khách hàng của Optimistic light sẽ phụ thuộc vào Celestia TMLC. Ngoài ra, đối với Tổng hợp bi quan hợp lý, bạn có thể có các cài đặt sau:
· Một khách hàng Tendermint Light (TMLC) thay mặt Celestia thực hiện việc cung cấp dữ liệu và bằng chứng đặt hàng giao dịch.
· Một ứng dụng khách nhẹ Tendermint (TMLC) với các quy tắc có điều kiện của Celestia để thực hiện bằng chứng thực thi thay mặt cho Rollup bi quan.
- Một lần nữa, quy tắc này sẽ đảm bảo rằng một khối có sẵn trên mạng Celestia trước khi nó được hoàn thiện.

Eigenlayer cho phép người xác thực Ethereum đặt lại số cổ phần Ethereum của họ vào các điều kiện cắt giảm bổ sung có thể được thực thi trên chuỗi. Điều này cho phép chuỗi tiêu dùng Eigenlayer mượn tính bảo mật của mạng Ethereum.
Bằng cách thêm điều kiện cắt giảm trên Ethereum, người xác thực EigenLayer có thể ký vào tiêu đề chuỗi tiêu dùng để cải thiện bảo mật . Nếu EigenLayer tích hợp IBC, xác thực chuỗi chéo có thể được sử dụng để thêm trình xác thực EigenLayer vào bộ trình xác thực đang hoạt động của chuỗi tiêu dùng. Mặt khác, chuỗi tiêu dùng vẫn có thể cung cấp một số mức độ bảo vệ cho các chuỗi được kết nối ở cấp liên kết IBC.
Điều này sẽ đạt được bởi:
· Các đầu chuỗi có chữ ký kép bị cắt trên Ethereum, điều đó có nghĩa là nếu người xác thực EigenLayer là người tiêu dùng Nếu chuỗi ký hai lần vào tiêu đề chuỗi, 1/3 số tiền cam kết trên EigenLayer sẽ bị hủy bỏ.
· Một chuỗi khối được kết nối với chuỗi tiêu dùng EigenLayer do IBC hỗ trợ cần chạy hai ứng dụng khách nhẹ - Một cho EigenLayer và một cái khác cho chuỗi tiêu dùng.
· Chuỗi được kết nối sẽ xác minh xem tiêu đề chuỗi đã được chuỗi tiêu dùng và EigenLayer ký hay chưa trước khi chấp nhận nó.
· Điều này có nghĩa là các kết nối IBC với chuỗi tiêu dùng EigenLayer có thể được phân nhánh và cung cấp thêm biện pháp bảo vệ kinh tế trước các cuộc tấn công.

Đối với Babylon, nó sẽ cung cấp dịch vụ điểm kiểm tra hoặc dấu thời gian, sử dụng bảo mật của Bitcoin để xử lý các giao dịch cụ thể bằng cách xuất bản dấu thời gian tổng hợp cho Bitcoin. Nó hoạt động như một nhà sản xuất bảo mật, trong khi các chuỗi được kết nối được coi là người tiêu dùng bảo mật.
Bằng cách kết nối với Babylon, chuỗi tiêu dùng có thể kết nối các trạm kiểm soát của nhà nước với Bitcoin để thực hiện các giao dịch có giá trị cao tận dụng tính bảo mật của Bitcoin. Ngoài ra, họ phải thực thi các quy tắc xác nhận chậm để trì hoãn việc hoàn tất các giao dịch này nhằm đảm bảo rằng trạng thái điểm kiểm tra đạt đến độ sâu *k-* trong mạng Bitcoin.
Xem hoạt động của IBC mô-đun trên chuỗi tiêu dùng Babylon:
· Khởi tạo ứng dụng khách cục bộ bằng cách sử dụng các quy tắc có điều kiện của Babylon TMLC.
- Quy tắc này sẽ đảm bảo rằng các gói được gửi được kiểm tra điểm trước khi thực hiện.
· Ghi một gói trên kết nối/kênh cục bộ đã khởi tạo.
- Các gói sẽ không được thực thi cho đến khi được kiểm tra và cam kết.
· Gửi dữ liệu có giá trị cao từ người tiêu dùng Babylon chuỗi Chuỗi gói đến kết nối IBC:
- Trước tiên hãy triển khai quy tắc xác nhận chậm đối với kết nối/kênh cục bộ.
- Gói tin sau đó sẽ được gửi qua kết nối IBC đến chuỗi được kết nối với IBC.

p>
Được đồng tổ chức bởi Polymer Labs với nhiều đối tác trong hệ sinh thái của chúng tôi trong ETH Denver 2023 đã chia sẻ hội nghị thượng đỉnh an ninh May mắn thay, những người bạn của chúng tôi tại Eigenlayer và Babylon Chain đã ghi lại Tất cả các cuộc thảo luận.
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

