Giải thích chi tiết cách Ethereum 2.0 hợp nhất với 1.0
Lưu ý của biên tập viên: Bài viết này đến từThông tin Babbitt (ID: bitcoin8btc)Lưu ý của biên tập viên: Bài viết này đến từ
Thông tin Babbitt (ID: bitcoin8btc)
Lưu ý: Tác giả gốc là Danny Ryan (djrtwo), điều phối viên của Ethereum 2.0. Trong bài viết này, anh ấy đã giới thiệu chi tiết cách thức Ethereum 1.0 sẽ hợp nhất với Ethereum 2.0. Theo lời giới thiệu của anh ấy, trong ứng dụng khách kết hợp eth1+eth2, eth2 khách hàng có thể xử lý sự phức tạp của PoS và sự đồng thuận phân đoạn, và khách hàng eth1 được đính kèm có thể trở thành một công cụ eth1, có thể xử lý sự phức tạp của những thứ như trạng thái, giao dịch, máy ảo, v.v.
Mô tả hình ảnh
(hình ảnh từ tuchong.com)<-> eth2 tiêu đề phụMối quan hệ giữa các máy khách Ethereum 1.0 và Ethereum 2.0
Kể từ khi Vitalik đề xuất sớm eth1 vào tháng 12 năm 2019
Kể từ đó, đã có những cuộc thảo luận tích cực giữa các nhà nghiên cứu để xem xét các hình thức hợp nhất có thể có này từ góc độ phần mềm và kỳ vọng về việc tạo nguyên mẫu chỉ ngày càng lớn hơn. Tầm nhìn của chúng tôi là tạo ra một hỗn hợp trong đó công việc đồng thuận cốt lõi được quản lý bởi ứng dụng khách Ethereum 2.0 (sau đây gọi là ứng dụng khách eth2), trong khi trạng thái/khối được quản lý bởi công cụ Ethereum 1.0 (sau đây gọi là công cụ eth1) và Họ cùng nhau tạo thành ứng dụng khách kết hợp eth1+eth2.
Bài viết này nhằm mục đích phân tách rõ ràng hơn các trách nhiệm giữa ứng dụng khách eth2 và công cụ eth1 được đính kèm để cung cấp cơ sở tốt hơn cho cuộc trò chuyện, viết thông số kỹ thuật và tạo mẫu. Lưu ý rằng bài viết này không xác định các chi tiết cụ thể của giao thức (chẳng hạn như phương pháp chính xác mà ứng dụng khách eth1 gọi công cụ eth2) và mọi ví dụ có trong bài viết này chỉ nhằm mục đích hỗ trợ mô tả và thảo luận sau đó.
Để hiểu được nội dung của bài viết này, điều kiện tiên quyết là về cơ bản bạn phải làm quen với các khái niệm về Ethereum 2.0 và Ethereum phi trạng thái.
tiêu đề phụ
Phân công lao động rõ ràng
Tóm lại, những gì chúng tôi nghĩ về một ứng dụng khách eth2 ngày nay sẽ xử lý PoS cốt lõi cũng như sự đồng thuận phân đoạn. Về cơ bản, giao thức eth2 và ứng dụng khách eth2 được thiết kế rất tốt trong việc tạo và đạt được sự đồng thuận về một loạt "công cụ", là nhiều chuỗi phân đoạn chứa đầy dữ liệu và trạng thái (cuối cùng). So với lớp đồng thuận PoW hiện tại của eth1, "lớp đồng thuận" của eth2 tiên tiến và phức tạp hơn nhiều.
Ngày nay, ứng dụng khách eth1 có lớp đồng thuận mỏng và tương đối đơn giản, nó chỉ có một chuỗi và PoW xử lý hầu hết sự phức tạp trong phần cứng ngoài giao thức. Hầu hết sự phức tạp và tối ưu hóa của ứng dụng khách eth1 nằm ở lớp người dùng (bao gồm lưu trữ/quản lý trạng thái, đồng bộ hóa trạng thái, thực thi máy ảo, xử lý giao dịch, tổng hợp giao dịch, v.v.).
Sự tách biệt các mối quan tâm này tạo nên một cặp đôi đẹp khi eth1 được tích hợp vào eth2 dưới dạng phân đoạn, ứng dụng khách eth2 có thể xử lý sự phức tạp của PoS và sự đồng thuận của phân đoạn, và ứng dụng khách eth1 của công ty con có thể trở thành công cụ eth1, có thể xử lý trạng thái phức tạp , giao dịch, máy ảo và những thứ gần gũi hơn với vùng người dùng.
tiêu đề phụ
Thay đổi tối thiểu để đạt được giao tiếp địa phương
Có nhiều cách khả thi để kết hợp phần mềm máy khách eth1 và eth2 (chẳng hạn như hợp nhất hoàn toàn, nhập eth1 dưới dạng thư viện, thông qua giao thức liên lạc giữa hai phần mềm, v.v.), nhưng trong bài viết này, chúng tôi sẽ tập trung vào một trong những cách tốt nhất. Một cách tiếp cận mô-đun và xâm lấn tối thiểu - một giao thức giao tiếp gốc giữa các máy khách eth2 và các công cụ eth1 được đơn giản hóa.
Với sự đa dạng của việc triển khai máy khách eth1 và eth2, cách tiếp cận này giúp phần mềm máy khách không bị khóa ở cả hai bên, cho phép các nhóm khách hàng duy trì sự độc lập và tập trung vào các nỗ lực R&D của riêng họ, giữ cho dự án phần mềm phần lớn ổn định để tạo nguyên mẫu nhanh.
Vậy nó sẽ trông như thế nào?
Đại khái, một ứng dụng khách kết hợp eth1+eth2 sẽ trông như thế này:
Trong số đó, công cụ eth2 và công cụ eth1 chạy cùng nhau và giao tiếp cục bộ thông qua RPC do ứng dụng khách eth2 điều khiển.
Cả hai sẽ duy trì giao diện p2p của riêng mình, kết nối với các đồng nghiệp và xử lý các giao thức mạng liên quan đến từng miền cụ thể.
Ứng dụng khách Ethereum 2.0
Beacon Chain và Beacon State (các đối tượng đồng thuận cốt lõi xây dựng phần còn lại của hệ thống);
Chuỗi phân đoạn (1, chuỗi phân đoạn eth1, 2, nhiều chuỗi phân đoạn chỉ chứa dữ liệu);
Hoạt động của Mempool [không hiển thị] (Chứng thực, gửi tiền, thoát, v.v.)
Giao diện P2P (1, thông tin lớp đồng thuận, 2, bao gồm tin đồn về khối phân đoạn eth1);
RPC cho công cụ eth1 (tất cả các cuộc gọi được điều khiển bởi ứng dụng khách eth2);
Công cụ Ethereum 1.0
Máy ảo EVM (thực thi và xác minh các khối phân đoạn eth1);
Giao diện P2P (1. tin đồn về giao dịch trên Ethereum ngày hôm nay, 2. đồng bộ hóa trạng thái, 3. không có tin đồn về khối eth1);
đoàn kết
RPC từ máy khách eth2 (tất cả các cuộc gọi được điều khiển bởi máy khách eth2);
tiêu đề phụ
đoàn kết
Cụ thể, công cụ eth1 được đính kèm phải có quyền truy cập vào ứng dụng khách eth2, vì nó không thể duy trì sự đồng thuận của riêng mình. Trong PoW của Ethereum ngày nay, ứng dụng khách eth1 kiểm tra bằng chứng công việc, tạo cấu trúc cây và chạy quy tắc lựa chọn rẽ nhánh để tìm đỉnh của chuỗi. Trong eth2, các cơ chế này khá khác nhau, điều này đòi hỏi sự hiểu biết sâu sắc về sự đồng thuận cốt lõi của eth2. Ứng dụng khách eth2 cung cấp thông tin cập nhật về đầu chuỗi phân đoạn eth1 để công cụ eth1 có thể duy trì chế độ xem chính xác về trạng thái của eth1.
Vì công cụ eth1 hoàn toàn dựa vào ứng dụng khách eth2 để thúc đẩy sự đồng thuận, nên chúng tôi đề xuất rằng giao tiếp giữa ứng dụng khách eth2 và công cụ eth1 là tất cả các phương thức trên công cụ eth1 được gọi bởi ứng dụng khách eth2 (chẳng hạn như addBlock, getBlockProposal, v.v.). Điều này sẽ thực thi mối quan hệ người lãnh đạo/người theo dõi để giảm sự phức tạp của suy luận hệ thống và hạn chế logic nghiệp vụ mà công cụ eth1 yêu cầu.
Từ quan điểm đồng thuận cốt lõi và ứng dụng khách eth2, chuỗi phân đoạn eth1 được xử lý gần như giống hệt với tất cả các chuỗi phân đoạn khác (lựa chọn ngã ba, liên kết chéo, cấu trúc khối, chữ ký, v.v.). Sự khác biệt chính là nội dung khối phân đoạn có thể được thực thi đối với công cụ eth1, vì vậy định dạng của dữ liệu khối phân đoạn eth1 phải tương ứng với eth1 và phải thực hiện xác minh bổ sung để thực thi thành công này.
tiêu đề phụ
tình trạng
eth2 có một trạng thái liên quan đến sự đồng thuận cốt lõi, được gọi là "trạng thái báo hiệu". Dữ liệu trạng thái đèn hiệu nhỏ (chỉ khoảng 10-40 MB, tùy thuộc vào kích thước của bộ trình xác thực) và dữ liệu này chứa tất cả thông tin cần thiết để hiểu sự đồng thuận cốt lõi và cách xử lý chuỗi phân đoạn. Trên thực tế, để xử lý các phần liên quan đến sự đồng thuận của chuỗi phân đoạn, khách hàng phải có quyền truy cập vào trạng thái báo hiệu (ví dụ: liên kết chéo mới nhất đang chạy cuộc bầu chọn ngã ba chuỗi phân đoạn, bộ xác thực hiện tại hoặc xáo trộn được chỉ định ngẫu nhiên).
Trạng thái của eth2 sẽ không phải lúc nào cũng tương tác với trạng thái của lớp người dùng và tương tác quan trọng nhất là tính khả dụng của dữ liệu chuỗi phân đoạn. Gốc dữ liệu lớp người dùng thực tế được đặt trong dữ liệu chuỗi phân đoạn và đối với chuỗi phân đoạn eth1, nó là gốc trạng thái người dùng Ethereum hiện tại.
Các trường hợp khác nhau về trạng thái eth1 liên quan đến ứng dụng khách eth2 được thảo luận bên dưới:
3. Đối với ứng dụng khách eth2 có công cụ eth1 có trạng thái để chạy trình xác thực có thể tạo các khối phân đoạn eth1, ứng dụng đó phải sử dụng một công cụ eth1 bổ sung và hoàn thành trạng thái eth1 để chạy giao thức eth2 (các nhà phát triển đang khám phá các phương pháp tạo khối không trạng thái, nhưng chúng tôi có không thảo luận về nó cho đơn giản). Sau đó, các khối hợp lệ mới có thể được hình thành theo yêu cầu bằng cách sử dụng nhóm bộ nhớ giao dịch và trạng thái cục bộ (bộ nhớ TX) (thêm về điều này bên dưới).
mạng
Ngoài trình xác thực, nhiều nút người dùng/ứng dụng cũng có thể chạy với một công cụ eth1 đầy đủ trạng thái, chẳng hạn như trình khám phá khối, nút lưu trữ, nhà cung cấp trạng thái, v.v.
mạng
ENR
Để đơn giản, eth2 và eth1 ban đầu sẽ duy trì các giao thức và ngăn xếp mạng riêng biệt của chúng. Để đáp ứng các trách nhiệm thay đổi (ví dụ: tin đồn về khối phân đoạn eth1), các nhà phát triển đã loại bỏ một số giao thức eth1 hiện có (ví dụ: tin đồn về khối phân đoạn eth1) và thay thế chúng bằng giao thức eth2. Sau giai đoạn tạo mẫu ban đầu hoặc ở giai đoạn tiếp theo, có thể cần phải di chuyển giao thức eth1 sang libp2p để hợp nhất ngăn xếp mạng, nhưng điều này là không bắt buộc.
Máy khách eth2 và công cụ eth1 có quyền truy cập vào cùng một discv5 DHT, nhưng độc lập tìm các đồng nghiệp có khả năng phù hợp và duy trì kết nối một cách độc lập.
tiêu đề phụ
chức năng eth1 (trạng thái, giao dịch, v.v.) được thể hiện bằng khóa eth (hoặc eth1 mới) hiện có trong ENR.
Chức năng eth2 (đồng thuận cốt lõi) được biểu thị bằng khóa eth2 trong ENR.
Sự tồn tại của mỗi giao thức có nghĩa là các nút có thể và sẵn sàng xác định loại giao thức mạng cơ bản.
tiêu đề phụ
giao thức dây
1. giao thức eth2 1. yêu cầu/phản hồi eth2 (1. Trạng thái, 2. Đồng bộ hóa khối báo hiệu, 3. Đồng bộ hóa khối phân đoạn); 2. Tin đồn về sự đồng thuận cốt lõi (1. Khối báo hiệu, 2. Bằng chứng, 3. khối, bao gồm phân đoạn eth1 , 4, các hoạt động của trình xác thực khác); 2, giao thức eth1 1, tập hợp con của giao thức dây eth1 (1, tin đồn giao dịch, 2, phương thức đồng bộ hóa, chẳng hạn như getnodedata hoặc phương thức mới, 3, nhận biên lai biên lai)
3. Tại sao ứng dụng khách eth2 xử lý tin đồn về khối eth1?eth2 được sử dụng đặc biệt để xử lý việc sản xuất, tin đồn và xác minh các khối phân đoạn. Mục tiêu của chúng tôi là phân đoạn eth1 trở thành tiêu chuẩn và nhất quán nhất có thể với các phân đoạn còn lại. Về sự đồng thuận cốt lõi, sự khác biệt chính của các khối eth1 so với các phân đoạn khác là khả năng thực thi/xác minh nội dung khối dựa trên công cụ eth1,
Khi trình xác thực đang rẽ nhánh khối phân đoạn eth1 vào chuỗi đèn hiệu, ứng dụng khách eth2 sẽ gọi lại công cụ eth1 để thực thi và xác thực khối.
Khi nút kết hợp eth1+eth2 có trạng thái nhận được khối phân đoạn eth1 mới, ứng dụng khách eth2 sẽ gọi lại công cụ eth1 để xác thực khối và cập nhật kho lưu trữ trạng thái cục bộ.
tiêu đề phụ
Tin đồn giao dịch và hồ bơi lưu trữ mempool
Các khối phân đoạn eth1 được cung cấp cho công cụ eth1 từ ứng dụng khách eth2 được đính kèm. Các giao dịch được bao gồm trong các khối này phải được xóa khỏi nhóm lưu trữ theo cách tương tự như các khối PoW mạng chính Ethereum hiện tại.
khối sản xuất
Các khối phân đoạn eth1 được tạo từ nội dung của mempool nhóm lưu trữ theo ứng dụng khách eth2 được đính kèm. Phương thức RPC này và chức năng cơ bản tương tự như getWork, nhưng sẽ trả về toàn bộ nội dung khối chứ không chỉ một hàm băm.
tiêu đề phụ
khối sản xuất
Đối với các khối đèn hiệu và khối phân đoạn không phải eth1, ứng dụng khách eth2 có mọi thứ cần thiết để tạo các khối hợp lệ.
Đối với các khối phân đoạn eth1, các máy khách eth2 có quyền truy cập ngay lập tức/bất cứ lúc nào vào trạng thái eth1, giao dịch và các cấu trúc eth1 cơ bản khác để tạo các khối hợp lệ. Ngược lại, khi trình xác thực được chỉ định tạo khối eth1, ứng dụng khách eth2 sẽ yêu cầu dữ liệu khối eth1 khả thi (TX, gốc trạng thái, v.v.) từ công cụ eth1. Sau đó, ứng dụng khách eth2 gói dữ liệu khối eth1 này thành một khối phân đoạn hoàn chỉnh (thêm vị trí, positer_index, positer_signature, v.v.) và phát khối này lên mạng.
Công cụ eth1 có thể tạo dữ liệu khối eth1 hợp lệ/khả thi vì nó quản lý nhóm lưu trữ giao dịch eth1 giống như cách mà mạng chính ethereum sử dụng ngày nay và nó duy trì trạng thái đầu eth1 mới nhất thông qua các bản cập nhật từ thông tin ứng dụng khách eth2.
tiêu đề phụ
Bước tiếp theo là gì?
Nếu thiết kế chung này được đồng ý, các bước tiếp theo bao gồm:
Đảm bảo rằng các giả định về ứng dụng khách eth2 điều khiển công cụ eth1 nhất quán với phần mềm eth1 hiện có và không áp đặt gánh nặng ngoài ý muốn lên phần mềm eth1 hiện có;
Xác định rõ hơn giao thức truyền thông được sử dụng để điều khiển công cụ eth1, chẳng hạn như new_head(block), validate_block_transition(block), get_proposal(parent_root), v.v.;
Xác định các thành phần mạng, chẳng hạn như tập hợp con nào của giao thức eth1 được yêu cầu và cách sử dụng cụ thể ENR;
