Vitalik: Về cầu nối hai chiều giữa eth1 và eth2
Tiêu đề gốc: "Vitalik: Trên cầu nối hai chiều giữa eth1 và eth2"
Nguồn gốc: Unitimes
Mục đích của bài viết này là giải thích một số thách thức trong việc thiết lập cầu nối hai chiều giữa chuỗi eth1 và chuỗi eth2 (ví dụ: hỗ trợ chuyển đổi hai chiều của ETH) và cách triển khai nó.
Đề xuất Eth2 đã bao gồm cầu nối một chiều từ eth1-> eth2, điều cần thiết để có thể thế chấp ETH bằng Eth1 cho eth2. Cầu nối một chiều này được thực hiện thông qua cơ chế bỏ phiếu dữ liệu eth1 [1]. Xin lưu ý rằng cơ chế này giả định rằng phần lớn các trình xác thực PoS đều trung thực và chuỗi PoW không bị tấn công (cụ thể, thời gian khôi phục trong chuỗi PoW sẽ không vượt quá 5 giờ).
Nếu một trong hai giả định này không thành công thì hai chuỗi eth1 và eth2 sẽ không còn "nhất quán" với nhau nữa. Đã có một “khế ước xã hội” ngầm ngay từ đầu, đó là Nếu có sự cố gì xảy ra sẽ có biện pháp khắc phục, rất có thể thông qua phần mềm của chuỗi PoS.Fork để khắc phục, tuy nhiên, cũng có khả năng nếu quá trình khôi phục chuỗi PoW vượt quá 5 giờ, cộng đồng có thể đạt được sự đồng thuận rằng chuỗi tấn công không hợp lệ. Cần lưu ý rằng trong bất kỳ trường hợp nào, sự thất bại của chuỗi PoS khó có thể đòi hỏi một fork mềm của chuỗi PoW.
Nếu chúng ta muốn chuỗi eth1 biết trạng thái của eth2 (đây là điều kiện tiên quyết để cho phép chuyển ETH từ eth2 trở lại eth1), có hai cách để đạt được điều đó:
· One Là ứng dụng khách nhẹ cho phép chuỗi PoW chấp nhận chuỗi PoS (xem hình đầu tiên bên dưới);
· Việc còn lại là làm cho trạng thái cuối cùng của PoS cũng được hoàn thiện chuỗi PoW (xem hình thứ hai bên dưới).
Phương pháp thứ hai có thể đạt được bằng cách thêm cơ chế sau, nghĩa là, nếu khối PoS B được biểu quyết thông qua eth1_data chứa một con trỏ tới khối PoW Bw Tham khảo, Khi khối B được xác nhận, Bw cũng có thể được coi là đã được xác nhận. Nhưng điều này có nghĩa là các công cụ khai thác PoW (và khách hàng) cũng cần chạy triển khai eth2 để họ biết chuỗi eth2 nào được xác nhận.
Phương thức đầu tiên yêu cầu triển khai ứng dụng khách eth2 trong eth1 . Điều này sẽ yêu cầu hỗ trợ webassembly hoặc gốc để xác thực BLS-12-381, đừng mong đợi hỗ trợ này sẽ sớm được triển khai. Ngoài ra, phương pháp này chỉ cung cấp bảo mật ở cấp độ máy khách nhẹ.
Cách tiếp cận thứ hai thú vị hơn vì nó cung cấp phiên bản "gốc" của các hạn chế khôi phục cho eth1 (thường được gọi là "đề xuất tiện ích cuối cùng"). Lưu ý rằng điều này khác với cách tiếp cận đầu tiên ở chỗ mặc dù nó làm cho lựa chọn phân nhánh của eth1 nhận biết được trạng thái của eth2, nhưng nó không ngay lập tức làm cho eth1 nhận biết được trạng thái của eth2.
Ví dụ: về mặt lý thuyết, hai chuỗi eth2 cạnh tranh có thể xác nhận cùng một khối eth1 (có nghĩa là eth2 không hoạt động, nhưng về mặt lý thuyết vẫn có thể xảy ra).
Một tình huống phổ biến hơn là chuỗi eth2 xác nhận hai khối, một trong số đó là khối con của khối kia và cả hai khối đều hỗ trợ cùng một khối eth1, vì vậy một số thợ mỏ có thể biết trạng thái gần đây của những khối này hai khối eth2, trong khi các công cụ khai thác khác thì không. Đây không phải là vấn đề đối với "eth2 với tư cách là tiện ích trạng thái cuối cùng", nhưng điều đó có nghĩa là chúng tôi cần thiết kế cấp thấp hơn để làm cho eth1 nhận biết được trạng thái khối của eth2 nhằm cho phép rút ETH khỏi Hợp đồng tiền gửi.
Một khả năng là chỉ cần tạo cơ chế bỏ phiếu eth2_data trong eth1;Về cơ bản, hãy sao chép cơ chế tương tự giúp eth2 nhận biết trạng thái của eth1 . Điều này có thể được kết hợp với giải pháp trên để đảm bảo tính nhất quán: thợ mỏ eth1 sẽ chỉ bỏ phiếu cho các khối eth2_data nếu chúng đáp ứng (i) đã xác nhận và (ii) được tham chiếu eth1_data khối là diện tích của eth1 mà người khai thác đang đóng gói Tổ tiên của các khối.
Thách thức
Cả hai phương pháp đều yêu cầu thay đổi eth1. Hiện tại không có thay đổi nào đối với eth1 trong lộ trình eth2 trước "chuyển đổi cuối cùng". Cả hai phương pháp đều yêu cầu hành động khắc phục khẩn cấp từ phía eth1 nếu phía eth2 bị hỏng. Cách tiếp cận thứ hai sẽ yêu cầu tất cả các công cụ khai thác eth1 cũng chạy các nút eth2. Vì vậy, mặc dù cả hai cách tiếp cận này đều chắc chắn có thể thực hiện được nhưng chúng sẽ không sớm xảy ra.
Tuy nhiên, khi eth2 tiếp tục hoạt động và chứng minh tính mạnh mẽ của nó, chắc chắn sẽ đến một giai đoạn mà việc triển khai một cây cầu như vậy sẽ có ý nghĩa. Để giảm thiểu rủi ro, bạn có thể thực hiện một số điều sau:
· Chạy các cuộc thăm dò eth2 trên eth1 với thời gian bỏ phiếu là một tuần để có thời gian can thiệp thủ công nếu có vấn đề phát sinh;
· Vì lý do tương tự, khi eth1 biết khối cuối cùng trong eth2 thông qua ứng dụng khách nhẹ, việc rút ETH cũng sẽ bị chậm trễ một tuần;
· Khi số tiền thế chấp ETH đủ lớn (chẳng hạn như Chỉ bật cầu này khi có hơn 5 triệu);
· Đặt ngưỡng biểu quyết cao hơn 50% (ví dụ: 80%); và làm cho hệ thống có xu hướng không bao gồm bất kỳ khối eth2 nào (trừ khi các khối này đạt được sự đồng thuận mạnh mẽ).
Liên kết gốc:
https://ethresear.ch/t/two-way-bridges- between-eth1-and-eth2/6286
Liên kết tham khảo:
[1]:https://github.com/ethereum/eth2.0-specs/blob/fffdb247081b184a0f6c31b52bd35eacf3970021/specs/core/0_beacon-chain.md
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
Bài viết liên quan
