Tiến độ Ethereum Giai đoạn 2 (2019-12)

以太坊爱好者

特邀专栏作者

2019-12-17 09:00 (UTC+8)

Bài viết này có khoảng 8647 từ, đọc toàn bộ bài viết mất khoảng 13 phút

Công việc trên Ethereum 2.0 Giai đoạn 2 tiếp tục phát triển. Bài viết này mô tả những phát triển mới nhất như bây giờ.

Tóm tắt AI

Công việc trên Ethereum 2.0 Giai đoạn 2 tiếp tục phát triển. Bài viết này mô tả những phát triển mới nhất như bây giờ.

Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans)Lưu ý của biên tập viên: Bài viết này đến từ

Những người đam mê Ethereum (ID: ethfans)

, Tác giả: Will Villanueva, bản dịch & hiệu đính: A Jian & Zeng Mi, được Odaily sao chép với sự cho phép.

Công việc trên Ethereum 2.0 Giai đoạn 2 tiếp tục phát triển. Bài viết này mô tả những phát triển mới nhất như bây giờ. Hầu hết công việc trong Giai đoạn 2 được thực hiện với sự cộng tác giữa nhóm Ewasm và nhóm Quilt tại Ethereum Foundation.

Nội dung trong các phần khác nhau của bài viết này thường hướng đến các lĩnh vực khác nhau, ít có sự giao thoa nên các bạn hãy chọn phần mình thích để đọc. Trước khi đọc bài viết này, tôi thực sự khuyên bạn nên tìm hiểu kiến thức nền tảng về Giai đoạn 2 và đề xuất môi trường thực thi (EE) thông qua các tài liệu sau:

Đường đến Eth 2 Giai đoạn 2 và mạng thử nghiệm Giai đoạn 2 (đây là bài nói chuyện từ Devcon 5 và các slide được sử dụng cho bài nói chuyện)

Diễn giải chuyên sâu của EthHub về Ethereum 2.0 Giai đoạn 2

Du lịch vòng quanh ETH2 Giai đoạn 2 (một số điểm kiến thức đã lỗi thời)

Ewasm 2.0: State Enforcement in Eth2.0 (đọc nâng cao)

tiêu đề cấp đầu tiên

Thay đổi lớp giao thức ảnh hưởng đến giai đoạn 2

Đề xuất 2 của Vitalik tinh chỉnh Đề xuất 1 và khái niệm mới về Eth2 như một giao thức không trạng thái (bài đăng trên blog này có một phần có tiêu đề "Chuỗi phân đoạn không cần trạng thái", giải thích ngắn gọn trạng thái không trạng thái là gì).

Thiết kế Giai đoạn 2 hiện tại không khác biệt đáng kể so với các ý tưởng của Đề xuất 2. Về mặt lịch sử, các phần của đề xuất đã thay đổi khi khái niệm cân bằng tải chuỗi đèn hiệu được giới thiệu. Ý tưởng cân bằng tải này đề xuất hiểu một chuỗi phân đoạn như một quá trình tính toán thuần túy, sau đó EE có thể chạy động trên chuỗi phân đoạn được chỉ định trước. Về cơ bản, ý tưởng này là cân bằng tải điện toán cho các chuỗi phân đoạn khác nhau thông qua hợp đồng cân bằng tải được xác định trên chuỗi đèn hiệu. Điều đáng nhấn mạnh là khái niệm thiết kế này rất thú vị và có thể thực hiện nhiều chế độ giao dịch đồng bộ giữa các phân đoạn khác nhau thông qua các bộ chuyển tiếp hợp tác. Nó đáng được nỗ lực hơn nữa cho nghiên cứu của chúng tôi.Nếu đáng tin cậy, chúng tôi có thể thêm công cụ này vào chuỗi phân đoạn trong tương lai (có thể sau khi nó trực tuyến).

tiêu đề cấp đầu tiên

Scout

Chúng tôi đã đạt được tiến bộ đáng kể trong việc xây dựng nguyên mẫu và triển khai sớm môi trường thực thi. Trước tiên, chúng ta cần xác minh rằng môi trường thực thi có thể hoạt động ở chế độ không trạng thái. Lượng dữ liệu bằng chứng/nhân chứng cần thiết cho môi trường hành quyết này có quá lớn không? Sẽ mất quá nhiều thời gian để sử dụng bằng chứng để thực hiện chuyển đổi trạng thái? Để trả lời những câu hỏi này, chúng tôi đã tạo ra nhiều môi trường thực thi và sử dụng chúng để nghiên cứu những câu hỏi này.Tuy nhiên, trước tiên chúng tôi cần một công cụ để xây dựng nguyên mẫu: Scout.

tiêu đề phụ

Scout là một công cụ tạo mẫu quy trình thực thi Giai đoạn 2 của Ethereum 2.0 (ban đầu được phát triển bởi Alex Beregszaszi), đã phát triển một trình bao bọc cho API Ewasm, vì vậy các nhà phát triển có thể sử dụng nó để xây dựng một nguyên mẫu của môi trường thực thi và tiến hành kiểm tra điểm chuẩn ( đo điểm chuẩn). Và nó cũng có tập lệnh lắp ráp và cổng C++.

tiêu đề phụ

EE liên quan đến Eth1

Để hỗ trợ việc chuyển đổi từ Eth1 sang Eth2, chúng ta cần biến các quy tắc chuyển đổi trạng thái của Eth1 thành môi trường thực thi trong Eth2. Thách thức chính của quá trình chuyển đổi này là chuyển đổi Eth1 sang mô hình không trạng thái, sau đó chuyển đổi EVM và mô hình giao dịch/tài khoản sang môi trường thực thi. Các EE được đề cập dưới đây là tiền thân của Eth1 EE. Một nhóm làm việc gần đây đã được thành lập để tập trung nhiều vào phát triển xung quanh Eth1 EE. Họ cùng nhau lập một kế hoạch làm việc ban đầu và vui lòng giới thiệu bản thân trên diễn đàn nghiên cứu về đạo đức.

Mã thông báo Cây Patricia Merkel (SMPT) không quốc tịch

Nguồn chính: Github, bài thuyết trình của Sina Mahmoodi tại Devcon 5

Nguyên mẫu đầu tiên của mã thông báo phi trạng thái EE nhằm bắt chước kiến trúc của Eth 1.0. Nó sử dụng cơ sở mã của tính chẵn lẻ để triển khai cây trạng thái Eth1 (Hexary Merkle-Patricia Trie) và các quy tắc mã hóa RLP. Nó cũng kết hợp triển khai bộ chuyển tiếp cơ bản cho phép bộ chuyển tiếp tạo nhiều bằng chứng cho một tập hợp các giao dịch.

Điểm chuẩn: 70 giao dịch và 5000 tài khoản/nút lá

Turbo Token

Thời gian thực hiện: 5 giây

Kích thước bằng chứng: 235 kb

Những cải tiến đáng kể vẫn cần thiết trong quá trình thực thi và kích thước bằng chứng, nhưng sự tiến bộ cũng được thể hiện rõ ràng từ những kết quả ban đầu này. Một trong những vấn đề liên quan đến việc biên dịch thư viện rỉ sét của Parity thành mã wasm, dẫn đến rất nhiều thao tác ghi nhớ (sao chép bộ nhớ) và các hoạt động kém hiệu quả khác. Nói chung, việc biên dịch từ gỉ sang web assembly đã được chứng minh là khá khó khăn. Ngoài ra, mục xác minh chữ ký mất 4 giây (trong tổng số 5 giây).

Thông tin chính: Tổng quan về Turboproof (Ghi chú của biên tập viên: xem siêu liên kết ở cuối bài viết để biết bản dịch tiếng Trung), Turboproof Rust Github, Turbo Token Github, bài phát biểu Devcon 5 của Guillaume Ballet, bài phát biểu Devcon 5 của Sina Mahmoodi

Công nghệ turboproofs được sử dụng trong mô hình Turbo Token ban đầu được nghiên cứu bởi Alexey Akhunov để triển khai ứng dụng khách ánh sáng không trạng thái Eth1. cập nhật cây dữ liệu. Casey Detrio và Sina đã phát triển một nguyên mẫu đơn nhánh ban đầu trong tập lệnh lắp ráp và rỉ sét để xác minh rằng động cơ phản lực có đủ hiệu quả hay không. Sau khi ban đầu thu được kết quả khả quan trên nguyên mẫu một nhánh, Casey đã triển khai mã thông báo bằng chứng turbo đơn giản và cơ bản nhất có thể sử dụng được EE với các tập lệnh lắp ráp. Sina Mahmoodi đã sao chép cách triển khai này và sau đó chuyển cơ sở mã và trình tạo cơ sở mã chống gỉ đầy đủ bằng chứng turbo của Guillaume sang bản thảo.

Điểm chuẩn: 70 giao dịch và 5000 tài khoản/nút lá

Thời gian trôi qua: 140 ms

Kích thước bằng chứng: 50 kb

Thông dịch viên EVM EE

tóm tắt

Chúng tôi cần phát triển trình thông dịch EVM (có sẵn trên web) trong một công cụ thực thi để hỗ trợ Eth1 EE. Hugo đã tạo một nguyên mẫu và thử nghiệm nó xung quanh hợp đồng add và mul256. Trong tương lai, nhiều hợp đồng và điểm chuẩn cần được giới thiệu để cải thiện nguyên mẫu này.

tóm tắt

Tất cả các công việc thử nghiệm được đề cập ở trên là để thực hiện triển khai môi trường thực thi Eth1. Chúng tôi đã bắt đầu xây dựng nguyên mẫu, nhưng vẫn còn nhiều vấn đề về hiệu suất cần xem xét. Như đã đề cập ở trên, một nhóm làm việc gần đây đã bắt đầu tập trung vào việc phát triển Eth1 EE và tạo ra một mô hình không trạng thái Eth1.

C Merkle Token

tiêu đề phụ

EE tập trung vào Eth2

Phần này sẽ giới thiệu các EE chưa được phát triển đầy đủ cho việc di chuyển Eth1 -> Eth2. Eth2 sẽ sử dụng môi trường thực thi dựa trên tài khoản mới, khác với mô hình tài khoản và giao dịch của Eth1, vì các mô hình giao dịch, tài khoản và bộ tích lũy được sử dụng bởi Eth1 là không tối ưu. Ngoài ra, các mô hình như tổng số lạc quan và tổng số ZK cũng nên được nghiên cứu. Không gian thiết kế cho Eth2 EE rất rộng mở và sau đây là những ý tưởng và nguyên mẫu ban đầu.

Thông tin chính: Github, Bản trình bày Devcon 5

Triển khai C của mã thông báo Merkle không trạng thái của Paul Dworzanski bằng cách sử dụng cây Merkle nhị phân (thay vì cây Merkle thưa thớt). Việc xác minh và cập nhật cây dữ liệu sử dụng phân phối bộ nhớ tối ưu và sắp xếp một định dạng đa bản duy nhất. Các hoạt động xác minh và cập nhật cây dữ liệu của mô hình này được hoàn thành trong một lượt (một lượt) (do đó tránh được các hoạt động sao chép bộ nhớ (memcopy và sao chép)) và rất có khả năng nó có thể được sử dụng trên cây dữ liệu thập lục phân của Eth1. Tuy nhiên, không rõ liệu thuật toán cập nhật cây dữ liệu có thể được sử dụng trên cây dữ liệu Eth1 hay không (vì mô hình dựa trên Eth1 thường sử dụng nhiều lượt).

Điểm chuẩn: 40 trong số 222 tài khoản liên quan đến bằng chứng

ZK Rollup

Thời gian đã trôi qua: 20 ms (không bao gồm xác minh chữ ký)

Kích thước bằng chứng: 25 kb

Shard Ether (Sheth)

Hiện tại, triển khai được sử dụng trong thử nghiệm đã là hiệu quả nhất. Xác minh chữ ký không được bao gồm trong tiêu chuẩn, nhưng chúng tôi ước tính rằng nó chỉ mất thêm 30 mili giây. Và có nhiều giải pháp tối ưu hóa hơn nữa, chẳng hạn như băm bộ đệm và bằng chứng để giảm thời gian và kích thước tính toán. Sơ đồ độ dài băm thích ứng (độ dài của hàm băm tăng lên khi mạng phát triển) cũng có thể giảm thêm kích thước bằng chứng. Cuối cùng, việc triển khai hàm băm tốt hơn dẫn đến thời gian tính toán ngắn hơn.

Thông tin chính: Tổng quan về ZK Rollup (Ghi chú của biên tập viên: Đối với bản dịch tiếng Trung, hãy xem siêu liên kết "ZK rollup vs. Optimistic rollup" ở cuối bài viết), bài phát biểu Devcon 5, ví dụ về trình xác minh stark EE, trình xác minh bằng chứng WASM, web snarks

ZK rollups là một giải pháp mở rộng Lớp 2. Bởi vì nó không sử dụng các cơ chế thử thách thoát và cơ chế khóa phức tạp nên nó có thể tránh được các vấn đề về trải nghiệm người dùng phổ biến trong các giải pháp Lớp 2 hiện có. So với các kế hoạch chuyển mã thông báo khác được liệt kê ở đây, ZK Rollup hạ cấp đáng kể các yêu cầu về tính khả dụng của dữ liệu. Các triển khai được liệt kê ở đây sử dụng web snark - một trình tạo được triển khai trong wasm có thể được sử dụng để xác minh snark hoặc các chức năng ghép nối khác. Để phát triển EE, Jared đã điều chỉnh websnark, phát triển một thư viện wasm riêng để xác thực bằng chứng Groth16. EE này vẫn là một nguyên mẫu ban đầu và phải tiếp tục được phát triển.

Nguồn chính: Github, Matt Garnett's Devcon 5 talk, Internal Quilt talk (chi tiết hơn), tổng quan về SSZ

Sheth là tiền thân của hợp đồng Eth2 EE (dựa trên Eth1, nhưng được lặp lại để làm cho nó phù hợp hơn với wasm/Eth2). Sheth dựa trên Thông số kỹ thuật mã hóa tuần tự hóa đơn giản (SSZ) được sử dụng trong Eth2, sử dụng sơ đồ cây Merkle thưa thớt, mượn mã opcode phản lực nhưng sử dụng một biểu mẫu khác để quản lý các yêu cầu đọc, ghi và cập nhật. Ý tưởng thiết kế của Diederik Loerakker là quyết định cách duyệt qua toàn bộ cây dữ liệu bằng cách lưu trữ một danh sách các giá trị bù đắp. Điểm mạnh của bằng chứng cây Merkle thưa thớt là bạn có thể xác định tĩnh tại thời điểm biên dịch chỉ mục tổng thể của dữ liệu bạn đang tham chiếu. Nó cũng đơn giản hóa đáng kể logic cần thiết để cập nhật trạng thái, vì các nút không bao giờ bị xóa hoặc chèn vào cây dữ liệu; tuy nhiên, có một số hy sinh (tính toán hàm băm cường độ cao) cho việc này. Sheth cũng bao gồm một ứng dụng khách dòng lệnh có thể hoạt động như một bộ chuyển tiếp hoặc nhà cung cấp trạng thái.

Điểm chuẩn: 50 tài khoản và 50 giao dịch

Kích thước bằng chứng: 517 kb

SimpleUmbrella — Hợp đồng thông minh Eth2 EE

Tài liệu chính: Đề xuất trong diễn đàn Nghiên cứu Eth, thực thi chức năng lưu trữ mã PR

tiêu đề cấp đầu tiên

Ewasm - Trình thông dịch, Trình biên dịch và Số liệu tính toán

tiêu đề phụ

người phiên dịch

tiêu đề phụ

thông dịch viên

tiêu đề phụ

chỉ số tính toán

Paul Dworzanski đã khám phá sâu lĩnh vực này trong buổi nói chuyện Devcon 5 của mình. Để đo tính toán, lệnh gọi use_gas đưa mã byte wasm (cho dù nó đang chạy trong EE hay ô EE) khi hợp đồng wasm được triển khai và xác minh. Sự phức tạp của việc tiêm và xác minh chắc chắn sẽ ảnh hưởng đến chi phí triển khai hợp đồng. Các điểm chuẩn hiện tại cho thấy mã wasm chạy chậm hơn 1,04-2,4 lần sau khi đưa vào các chỉ số tính toán. Điểm chuẩn các mẫu tốt hơn của quy trình tiêm và tập hợp sổ đăng ký sẽ chỉ ra các tối ưu hóa hơn nữa.

Nguyên mẫu Giai đoạn 1 và 2 trong ứng dụng Lighthouse hoặc mô phỏng Giai đoạn 2

Chúng tôi muốn mô phỏng cách xây dựng các ứng dụng khách của Giai đoạn 1 và 2 cũng như cách các nhóm phát triển triển khai sẽ được hỗ trợ. Chúng tôi cũng hy vọng sẽ sử dụng công việc này để mô phỏng và thử nghiệm EE chạy trên nhiều phân đoạn trong môi trường thế giới thực. Trong Devcon 5, tôi đã nói về mô phỏng mà chúng tôi đã xây dựng. Chúng tôi đã phát triển/giới thiệu một nguyên mẫu Giai đoạn 1 rất đơn giản (không thêm thành phần mạng nào) trong ứng dụng khách Lighthouse và bao gồm thời gian chạy Ewasm giai đoạn 2 trong ứng dụng khách. Chúng tôi tương tác với Sheth (Sheth đóng vai trò là người chuyển tiếp và nhà cung cấp trạng thái) và có thể mô phỏng chuyển EE hoặc mã thông báo cơ bản trong Lighthouse.

Bởi vì ứng dụng khách Lighthouse vẫn đang được tích cực phát triển, chúng tôi nhận ra rằng việc duy trì một nhánh của ứng dụng khách Lighthouse và phát triển trên nó có thể sẽ khó hơn chúng tôi nghĩ ban đầu. Vì vậy, chúng tôi quyết định lấy chất dinh dưỡng từ nguyên mẫu ban đầu và phát triển một phiên bản sơ khai trừu tượng bên trong Scout. Chúng tôi sẽ tiếp tục mô phỏng hoạt động của chuỗi đèn hiệu và chuỗi phân đoạn, nhưng chúng tôi có thể đơn giản hóa rất nhiều logic, bởi vì trọng tâm của chúng tôi là nghiên cứu môi trường thực thi và đo điểm chuẩn giữa các phân đoạn. Phần công việc này đang được quản lý bởi hai thành viên mới của nhóm Quilt.

tiêu đề cấp đầu tiên

John Adler đã viết một bài tổng quan rất toàn diện về chủ đề này. Bài viết của anh ấy cũng kể về một sự phát triển thú vị của đề xuất Eth2. Tóm lại, đề xuất đơn giản hóa sharding mới nhất của Vitalik đã loại bỏ nhiều vấn đề mà chúng tôi gặp phải với mô hình chuyển tiếp ngay từ đầu. Tuy nhiên, vẫn còn nhiều câu hỏi mở về cách các nhà cung cấp nhà nước gửi giao dịch đến các nhà sản xuất khối và cách các nhà sản xuất khối kết hợp các gói giao dịch vào một hệ thống đa bằng chứng phù hợp. Một trong những đề xuất là triển khai một môi trường thực thi mới với tập lệnh hợp nhất bằng chứng.

Cuối cùng, bộ chuyển tiếp hoặc nhà cung cấp trạng thái sẽ kế thừa điểm cuối RPC mà web3.js hoặc ethers.js được kết nối. Điều quan trọng là phải đưa ra một bộ tiêu chuẩn cho các hoạt động này trên nhiều EE.

tiêu đề cấp đầu tiên

Giao dịch chéo

tiêu đề phụ

Giao dịch chéo không đồng bộ
Đề xuất Giai đoạn 0 & 1 mới nhất của Vitalik là tin tốt cho cả giao dịch giữa các phân đoạn và khả năng kết hợp. Trong đề xuất mới, một cuộc gọi giữa các phân đoạn có thể được hoàn thành chỉ với một khoảng thời gian trễ (6 giây), trong khi ở đề xuất trước đây, một cuộc gọi phải đợi khoảng thời gian trễ từ 12 đến 18 phút mới được hoàn tất. Do đó, việc chuyển trạng thái (hoặc eth) của bạn giữa các phân đoạn trở nên rất nhanh chóng. Trước đây, chúng tôi muốn sử dụng các gốc lạc quan để tăng tốc cuộc gọi, nhưng nhận thấy rằng các giải pháp này rất phức tạp.
Từ quan điểm của nhà phát triển dApp, lệnh gọi phân đoạn chéo chỉ cần tuân theo mô hình và phương pháp không đồng bộ trong lập trình đa luồng. Khi viết hợp đồng thông minh, HLL (Slodity) và DSL (Vyper) cần cung cấp các công cụ cần thiết để trừu tượng hóa hành vi giữa các phân đoạn thành một mô hình không đồng bộ. Toàn bộ lược đồ rất có thể sẽ trông như thế này:
Các cuộc gọi không đồng bộ đơn giản (đang chờ không đồng bộ, gọi lại, v.v.)

Xác nhận hai pha (tính nguyên tử)

Khóa - Đọc/Ghi (Kéo hợp đồng)

Cần nghiên cứu thêm về cách hỗ trợ các mẫu này trong EE hoặc trong hợp đồng cơ bản. Các mô phỏng được đề cập ở trên (và các công cụ phối hợp được đề cập bên dưới) sẽ cung cấp cơ sở cho các thử nghiệm của chúng tôi với các mô hình này, nhưng thực sự, chúng tôi sẽ nói rằng đây là một lĩnh vực nghiên cứu quan trọng và nếu mọi người sẵn sàng tham gia, chúng tôi sẽ rất hạnh phúc. Chỉ định hành vi trước và sau xử lý ở cấp độ thấp hơn, như được mô tả trong bài đăng này, có thể cung cấp một khuôn khổ hợp lý để tạm dừng và sau đó tiếp tục thực hiện trong hợp đồng.

Đồng bộ hóa các giao dịch chéo

Trước đây, Vitalik đã xuất bản một bài viết thảo luận về các kế hoạch của nhà nước. Bản chất của các giải pháp này là chế độ Lớp 2 trên chuỗi và phân mảnh chỉ được sử dụng làm lớp sẵn có của dữ liệu. Các mô hình này (nghĩa là mô hình "thực thi trạng thái bị trì hoãn" huyền thoại trước đây, mô hình "thực thi lười biếng" hoặc "chuỗi bóng tối") thực sự là tiền thân của cái gọi là tổng số lạc quan. Việc sử dụng nhiều phân đoạn làm lớp dữ liệu sẵn có cho sơ đồ tổng số tối ưu giúp có thể đồng bộ hóa các giao dịch trên các phân đoạn. Chúng tôi có thể phát triển một nguyên mẫu dựa trên khái niệm này trong tương lai không xa.

tiêu đề phụ

Chúng ta có thực sự cần gọi qua các phân đoạn không?

Một quan điểm khác đáng để nghiên cứu thêm là nội dung chính của Eth2 nên nghiêng về các kênh trạng thái, các bản tổng hợp lạc quan và bản tổng hợp zk (sau khi các kế hoạch này hoàn thiện). Theo cách suy nghĩ này, bản thân Eth2 là một lớp dữ liệu sẵn có và các lệnh gọi phân đoạn chéo chỉ được sử dụng khi kết nối các sơ đồ này hoặc trong các thử thách thoát/bằng chứng sai. Các bản tổng hợp vẫn phải được xác định trong ranh giới của môi trường thực thi Eth1 hoặc Eth2, tuy nhiên, các tính toán chỉ cần được thực hiện trên chuỗi khi cần gửi bằng chứng lỗi.

tiêu đề cấp đầu tiên
Chuỗi công cụ giai đoạn 2
Để thúc đẩy nghiên cứu của mình, chúng tôi đề xuất một chuỗi công cụ mà các nhà phát triển cần sử dụng. Như đã đề cập trong phần "Nguyên mẫu Giai đoạn 1 và Giai đoạn 2 trong Lighthouse" ở trên, chúng tôi đang tích cực phát triển một bộ mô phỏng để thử nghiệm và chạy các môi trường thực thi trên các phân đoạn. Tuy nhiên, để tối ưu hóa chế độ hoạt động của hợp đồng thông minh, chúng tôi phải thêm rất nhiều công cụ điều phối. Bài đăng này giải thích các công cụ này sâu hơn.
Giai đoạn 1 & 2 Mô phỏng
Chèn môi trường thời gian chạy của máy khách Giai đoạn 1

Phần phụ trợ đa bằng chứng đáng tin cậy (cho phép khách hàng tạo, hợp nhất và quản lý đa bằng chứng)

Bộ chuyển tiếp, công cụ của nhà cung cấp trạng thái để tương tác với web3.js (xem phần "Bộ chuyển tiếp, nhà cung cấp trạng thái và thị trường phí")

Eth1 ->tiêu đề cấp đầu tiên
Những đóng góp khác của Vitalik cho Giai đoạn 2
Vitalik cũng đã thảo luận về các chủ đề liên quan đến Giai đoạn 2 trong các bài đăng khác gần đây, nhưng tôi không trích dẫn trực tiếp ở trên mà chỉ ra rằng:
Di chuyển ETH2
Thực hiện giao dịch cross-shard
Chính thức hóa và cải thiện phương pháp tiếp cận của Eth2 đối với phản hồi xác định đối với các khối phân đoạn không hợp lệ

Hợp đồng được lưu trên beacon chain

Khả năng kết hợp DeFi giữa các phân đoạn

Nếu bạn quan tâm đến việc giúp đỡ chúng tôi, vui lòng liên hệ và tham gia. Vui lòng tham gia kênh điện tín này để cập nhật hoặc đặt câu hỏi. Chúng tôi đã đạt được tiến bộ, nhưng vẫn còn rất nhiều việc phải làm.