Các chuỗi khối không liên quan cần phải có một cách để giao tiếp để người dùng có thể tương tác với dữ liệu và tài sản trên nhiều chuỗi khối một cách dễ dàng và vì vậy, giao thức Giao tiếp Giữa Các Chuỗi Khối (IBC) đã được thiết lập để hoạt động như một lớp vận chuyển giữa các chuỗi khối. Hệ sinh thái Cosmos đã áp dụng IBC trước, nhưng vì nó là một giao thức có thể tổng quát hóa, IBC đã tìm được đường vào nhiều hệ sinh thái khác.

ICS-02 chỉ rõ các yêu cầu cho việc xây dựng máy khách nhẹ, bao gồm cách IBC quản lý dữ liệu máy khách nhẹ. Các máy khách cần thiết cho IBC hoạt động, đó là các thuật toán xác minh tùy ý để chứng minh thông tin trên chuỗi, thông thường được mã hóa theo định dạng IBC, từ một nơi này sang nơi khác.

Từ quan điểm của IBC, mỗi chuỗi thường được xác định bởi light client của nó. Xác minh phổ biến nhất diễn ra giữa hai máy trạng thái đang giao tiếp; bằng cách sử dụng light client, một chuỗi nguồn có thể xác minh các cập nhật từ một chuỗi đích mà không cần tải xuống toàn bộ dữ liệu của nó. Do light clients là công cụ linh hoạt, chúng có thể sử dụng nhiều phương pháp để thực hiện xác minh trạng thái.

Xác minh chứng thực đồng thuận

Một lưu ý về thuật toán đồng thuận

Consensus blockchain đảm bảo rằng tất cả các nút tham gia vào mạng đều đồng bộ. Sử dụng xác minh đồng thuận, khách hàng nhẹ chứng minh rằng một số lượng đủ lớn các nhà xác minh đã ký vào tiêu đề. Loại xác minh này là việc sử dụng phổ biến nhất của IBC.

Các thuật toán đồng thuận thường khác nhau về tập hợp các quy tắc và ưu tiên của chúng. Tuy nhiên, sự đa dạng trong hai thuật toán đồng thuận khác nhau có thể khiến cho việc giao tiếp qua IBC trở nên khó khăn. Ví dụ, các chuỗi Cosmos sử dụng thuật toán đồng thuận Tendermint có độ tin cậy trên một khe cắm duy nhất, còn được biết đến là độ tin cậy nhanh. Ngược lại, đồng thuận của Ethereum không có độ tin cậy trên một khe cắm duy nhất và do đó chậm hơn vì nó đánh giá tính sống còn hơn tính bảo mật trong khi IBC tương thích nhất với các thuật toán đồng thuận đánh giá tính bảo mật. Do sự khác biệt này trong việc xem xét khi nào các khối được coi là 'cuối cùng', việc gửi và xác minh các khối giữa hai chuỗi trở nên khó khăn.

Trong trường hợp như vậy, một khách hàng ánh sáng ảo có thể được triển khai có thể nhìn thấy khách hàng ánh sáng ở một độ cao khối cụ thể trước khi đạt được tính chất cuối cùng. Ban đầu, IBC tập trung vào việc áp dụng của nó trong các chuỗi dựa trên Tendermint, điều này rõ ràng trong cách mà đặc tả và triển khai của khách hàng được xác định. Sau giai đoạn ban đầu này, Client Refactortăng tính linh hoạt và dễ dàng trong việc phát triển các máy khách nhẹ cho các chuỗi với các thuật toán đồng thuận và tính năng khác.

Khách hàng nhẹ: Máy quyết định trạng thái

Một “máy trạng thái” có thể là toàn bộ blockchain (sổ cái được sao chép) hoặc một quy trình đơn lẻ ký các hoạt động bằng khóa riêng (đồng thuận tối thiểu), chẳng hạn như một máy tính xách tay hoặc điện thoại di động.

Thường thì, chúng ta nghĩ về các máy trạng thái như các chuỗi khối với các sổ cái phân tán, vì vậy khi thiết lập IBC giữa các chuỗi khối, một ứng dụng nhẹ của chuỗi đích được lưu trữ bởi chuỗi nguồn. Chuỗi nguồn cũng duy trì một trạng thái đáng tin cậy của chuỗi đích, được thiết lập thông qua việc bắt tay kết nối giữa hai chuỗi. Giao thức IBC sử dụng một bộ kiểm chứng tính hợp lệ, đó là một thuật toán kiểm tra xem cập nhật trạng thái của chuỗi đích có hợp lệ không. Để hoạt động, một ứng dụng nhẹ cần một bộ kiểm chứng tính hợp lệ và một trạng thái đáng tin cậy cho chuỗi nguồn.

loại khách hàng so với phiên bản khách hàng

Các máy khách nhẹ được thiết kế để hiệu quả nhất có thể để hỗ trợ một số lượng lớn các phiên bản máy khách cho nhiều chuỗi. Để đạt được điều này, thuật toán máy khách nhẹ không phát lại tất cả các chuyển đổi trạng thái, điều này nếu không sẽ khiến nó trở thành một nút đầy đủ.

Khách hàng nhẹ: Các máy đơn lẻ

Một máy đơn là một thiết bị như một laptop, giao diện web, điện thoại di động hoặc một quy trình ngoại chuỗi. Một máy đơn có thể thiết lập giao tiếpvới một sổ cái được sao chép nếu blockchain đó sử dụng IBC cho việc vận chuyển.

Ví dụ, IBC có thể kích hoạt một giao thức chuyển giao bảo lưugiảm chi phí tích hợp cho các chuỗi mới. Điều này quan trọng vì người giữ quản trị tập trung đối diện với quy trình tẻ nhạt và tốn kém khi tích hợp mạng lưới mới, đòi hỏi chạy một nút đầy đủ và cơ sở hạ tầng RPC cho mỗi chuỗi tích hợp. Thay vào đó, người giữ quản trị có thể vận hành một máy khách đơn lẻ giúp chuyển giao qua chuỗi, đúc/nhận. Xác minh sẽ được tiến hành bởi máy khách kết nối chạy bởi người giữ quản trị.

Các khách hàng máy độc lập thể hiện cách IBC mở ra khả năng kết nối bên ngoài ngoài chỉ là các chuỗi khối. Trong ví dụ trên, nó có thể cho phép các tổ chức tương tác dễ dàng với các chuỗi khối công cộng thông qua IBC. Đây chỉ là một ví dụ về các dòng kinh doanh tiếp xúc với chuỗi khối mà không cần phải triển khai toàn bộ chuỗi hoặc duy trì phần cứng nặng để làm việc với chúng.

Xác minh vượt qua bằng chứng mồi dụ

Mặc dù có công việc đang được thực hiện để làm cho các khách hàng dễ triển khai và cập nhật, có tùy chọn để tiến hành xác minh với tính hợp lệ hoặc chứng minh gian lận.

Optimistic IBC: Các khách hàng có thể lạc quan chấp nhận các tiêu đề đến thông qua một người chuyển tiếp ngoại tuyến thực thi một chương trình trên một số máy ảo. Trong kịch bản này, có một cửa sổ thách thức nơi một bằng chứng gian lận có thể được gửi. Điều tích cực là rằng IBC Lạc quan giảm chi phí của toàn bộ hệ thống. Nhược điểm bao gồm thời kỳ thách thức gian lận dài và phụ thuộc vào mạng, có thể có chi phí cơ bản cao để chuyển tài sản - đối với Ethereum, đây là 21.000 đơn vị của gas.

ZK-IBC: Các phép tính của khách hàng xảy ra ngoại chuỗi và được xác minh trên chuỗi thông qua ZKPs. Không có độ trễ tối thiểu và chi phí thấp hơn so với việc xác minh ngây thơ. Tuy nhiên, việc xác minh ZK có thể tốn kém trên chuỗi và không có độ trễ tối đa, điều đó có nghĩa là người dùng có thể phải chờ một thời gian để nhận được xác nhận. Cũng có thể xảy ra vấn đề không tương thích nếu hệ thống ký không thân thiện với SNARK.

Bởi vì các hệ thống riêng biệt ở trên có thể có một số hạn chế không thể chấp nhận được, Optimistic ZK được đề xuất để mượn lợi ích từ cả hai. Các lợi ích của việc sử dụng cả hai giảm chi phí bảo trì kết nối và giới hạn độ trễ tối đa thông qua việc khuyến khích người truyền tải.

Optimistic ZK: Chuỗi nguồn chấp nhận tiêu đề một cách lạc quan trên chuỗi (có thể có cơ chế đặt cược để bảo mật). Sau đó, ZKP được sử dụng như chứng minh gian lận trong trường hợp hành vi xấu hoặc chứng minh tính hợp lệ để giảm độ trễ động của kết nối.

Bảo mật và Hành vi không đúng

IBC không yêu cầu bất kỳ giả thiết tin cậy của bên thứ ba nào, mà các giao thức tương thích được xác thực bên ngoài thường thực hiện. Đó chỉ là một giao thức vận chuyển và các thuộc tính bảo mật của nó phụ thuộc vào các loại khách hàng và kết nối cơ bản chứ không phải là chuỗi chính nó. Nó cũng phụ thuộc vào việc sử dụng chứng minh gian lận, giả thiết đa số trung thực, bảo mật chia sẻ thông qua khả năng truy cập dữ liệu chung, vv. Giao thức IBC không cần biết danh tính của các chuỗi ở cả hai bên của một kết nối, miễn là các khách hàng IBC được đồng bộ với các cập nhật hợp lệ.

Trong trường hợp xảy ra hành vi không đúng, tức là các quy tắc đồng thuận do chuỗi đích đặt được phá vỡ bởi khách hàng trên một chuỗi nguồn, khách hàng trên chuỗi máy chủ sẽ bị đóng băng nếu bằng chứng về hành vi không đúng được xác minh trên chuỗi nguồn. Bên đã chứng kiến điều này, như người chuyển tiếp, có thể gửi một tin nhắn kèm theo bằng chứng về hành vi không đúng này. Mệnh đề hành vi không đúng là một thuật toán được gọi trong các tình huống như vậy: nếu hành vi không đúng được chứng minh, khách hàng sẽ bị đóng băng và hy vọng rằng có một hệ thống quản trị đang hoạt động để có biện pháp. Những hậu quả của hành vi không đúng được quyết định bởi các chuỗi tham gia.

Xây dựng với Light Clients

Mặc dù IBC có thể đòi hỏi một số sự thành thạo kỹ thuật trong sự nhất quán và bên trong chuỗi cơ sở, nhưng không phải tất cả các sự phức tạp đều quan trọng để xây dựng bằng cách sử dụng IBC - một mục tiêu khác của chúng tôi với loạt bài viết này. Điểm cần nhớ ở đây là IBC là một công cụ mạnh mẽ khi có các triển khai xác minh khác nhau mà khách hàng có thể thực hiện.

Hệ sinh thái IBC đang tích cực làm việc để biến IBC thành một giải pháp dễ dàng cho các nhà xây dựng áp dụng. Một số sáng kiến mà chúng tôi đã thảo luận bao gồm tái cấu trúc khách hàng và khách hàng ảo. Ví dụ, nếu một chuỗi muốn nâng cấp sự đồng thuận, nó sẽ cần nâng cấp mỗi chuỗi mà nó kết nối đến và các khách hàng nhẹ của họ để duy trì kết nối, điều này là một quy trình quản trị trên chuỗi tốn kém. Khách hàng WASM đang được phát triển để làm cho việc phát triển và nâng cấp khách hàng nhẹ trở nên đơn giản thông qua các trường hợp khách hàng triển khai dưới dạng hợp đồng thông minh. Điều này làm cho việc nâng cấp khách hàng nhẹ trở nên dễ dàng mà không ngừng chuỗi và tạo ra khách hàng bằng các ngôn ngữ như Rust, đây là một lựa chọn phổ biến giữa một số máy trạng thái.

Phần quan trọng là khách hàng IBC có thể được sử dụng bởi bất kỳ ai và bất kỳ máy nào để xác minh trạng thái trên bất kỳ blockchain nào, khiến chúng trở thành một yếu tố thúc đẩy mạnh mẽ cho các doanh nghiệp và dịch vụ mới trong lĩnh vực tiền điện tử.

Bài viết này được tài trợ bởi Polymer để hỗ trợ việc giáo dục cộng đồng về IBC và sự tương tác thực sự phi tập trung.

Polymer Labs, được cấu thành từ các kỹ sư hệ thống phân tán và cơ sở hạ tầng kỹ thuật, những người tiên phong trong lĩnh vực tiền điện tử và các nhà điều hành kinh doanh thành công, đang ở vị trí dẫn đầu trong việc thúc đẩy tính tương tác của Ethereum với IBC. Với các giá trị kỹ thuật dựa trên TCP/IP, nhiệm vụ của Polymer là thiết lập thế hệ tiếp theo của internet bằng cách đảm bảo rằng lớp tương tác của web phi tập trung là trung lập, mở, không cần phép và đồng đều trên các hệ sinh thái. Là những người sáng tạo của Trung tâm Tương tác của Ethereum, tập trung vào Layer 2 đầu tiên về khả năng tương tác IBC, Polymer đặt ra một tiêu chuẩn mới trong công nghệ blockchain.

Miễn trừ trách nhiệm：

1. Bài viết này được sao chép từ [Gateeshitanandini]. Tất cả bản quyền thuộc về tác giả gốc [ESHITA]. Nếu có bất kỳ ý kiến phản đối nào về việc tái in này, vui lòng liên hệ vớiGate Họcđội ngũ và họ sẽ xử lý nhanh chóng.
2. Thông Báo Miễn Trừ Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.