Cơ chế phí và mạng chuyển tiếp của ETH2.0
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ả: John Adler, Người dịch & Người soát lỗi: IAN LIU & A Jian, được Odaily sao chép với sự cho phép.
lý lịch
lý lịch
Trước khi đi sâu vào mạng chuyển tiếp, hãy xem lại một trong những nút cổ chai chính của Ethereum (hoặc thiếu nó): trạng thái.
Trong Ethereum, trạng thái đề cập đến việc thu thập số dư tài khoản, mã hợp đồng và nội dung lưu trữ hợp đồng (trong Bitcoin, trạng thái đề cập đến việc thu thập UTXO). Bất cứ khi nào một giao dịch được thực thi, trạng thái (~45 GB dữ liệu không nén được) sẽ được đọc và ghi. Trước đó, mọi người đã đặt câu hỏi về khả năng không thể mở rộng tự nhiên của mô hình điện toán Ethereum; nhưng ngày nay, việc đọc và ghi trạng thái đã trở thành nút cổ chai chi phí để thực hiện các giao dịch và hiệu suất I/O của đĩa đã trở thành nút cổ chai cho việc chạy mạng đầy đủ của Ethereum.
Xin lưu ý rằng để có thể thực hiện bất kỳ giao dịch nào theo mô hình trạng thái (stateful paradigm), nút đầy đủ phải đảm bảo rằng tất cả các trạng thái luôn được đặt ở vị trí có thể truy cập (chẳng hạn như bộ nhớ, không gian hoán đổi). Nếu nó được áp dụng cho một kịch bản blockchain duy nhất, điều này có thể khó chấp nhận được, nhưng một khi phải đối mặt với sự phân mảnh và tổ chức lại ủy ban về phân mảnh, yêu cầu này là rất vô lý. Hãy tưởng tượng rằng mỗi khi một người xác minh được gán cho một chuỗi phân đoạn, anh ta phải đồng bộ hóa tất cả các trạng thái trên phân đoạn đó; thì hệ thống này tương đương với một chuỗi khối duy nhất, ngoại trừ kích thước khối tại thời điểm này bằng với kích thước khối phân đoạn * số lượng mảnh vỡ.
tiêu đề phụ
Sharding và khách hàng không trạng thái
Trong mô hình máy khách không trạng thái (trước đây gọi là "không lưu trữ"), trình xác thực chỉ cần lưu trữ bảng trạng thái chuỗi khối nén (thường được gọi là bộ tích lũy), giúp giảm đáng kể gánh nặng thực hiện giao dịch. Thông thường, kích thước của bộ tích lũy là không đổi (ví dụ: giá trị gốc cây Merkle của trạng thái), nhưng nó cũng có thể có kích thước logarit.
Bản chất của ứng dụng khách không trạng thái là mỗi giao dịch được kèm theo dữ liệu nhân chứng (nhân chứng) của bộ tích lũy hiện tại, dữ liệu này chứa tất cả thông tin cần thiết để thực hiện giao dịch. Trong Ethereum, sử dụng Sparse Merkle Tree (SMT, Sparse Merkle Tree) làm công cụ tích lũy, tất cả các yếu tố trạng thái liên quan đến giao dịch có thể được đưa vào các nhánh cây Merkle.
Trong các ứng dụng khác, các máy khách không trạng thái có thể rút ngắn thời gian đồng bộ hóa ban đầu của các nút Ethereum, đó là nguyên tắc của Beam Sync.
Lưu ý: Có một số bộ tích lũy mã hóa (chẳng hạn như bộ tích lũy RSA) hoạt động tốt hơn bộ tích lũy Merkle, nhưng những bộ tích lũy như vậy yêu cầu khởi tạo đáng tin cậy hoặc sử dụng các kỹ thuật mã hóa tiên tiến chưa được xác minh, vì vậy sẽ không an toàn khi triển khai chúng trên các hệ thống sản xuất. dành thời gian.
Nhưng các máy khách không trạng thái có những thách thức riêng: một khi bộ tích lũy Merkle được sử dụng, nhân chứng sẽ hết hạn mỗi khi quá trình thực thi đầy đủ kết thúc. Nếu mô hình yêu cầu mỗi giao dịch chứa một nhân chứng riêng biệt, sau đó thực hiện tuần tự các giao dịch này, thì dữ liệu nhân chứng của giao dịch sau sẽ lỗi thời và phải có thể cập nhật nhân chứng của chính nó khi hoàn thành từng giao dịch trước đó. May mắn thay, việc cập nhật nhân chứng của các bộ tích lũy Merkle này liên quan đến cách tiếp cận không băm - nếu dữ liệu nhân chứng có thể được thêm dưới dạng phần phụ vào "túi lớn" giao dịch, thì không cần cập nhật nhân chứng riêng lẻ thuộc từng giao dịch, hoặc có thể Tích hợp thành nhiều bằng chứng (multiproof).
Nếu tất cả người dùng duy trì các nút đầy đủ và cập nhật trạng thái nhân chứng trong thời gian thực, thì hệ thống máy khách không trạng thái có thể được áp dụng ngay lập tức. Thật không may, trong một môi trường phân đoạn, điều này có nghĩa là yêu cầu tất cả người dùng duy trì tất cả trạng thái trên phân đoạn của riêng họ, điều này không chỉ không thực tế, mà như chúng tôi đã đề cập ở trên, nó tương đương với việc chỉ tạo một khối có kích thước lớn hơn. .
Để giải quyết vấn đề, khái niệm về người chuyển tiếp (còn được gọi là nhà cung cấp trạng thái) được giới thiệu ở đây. Người chuyển tiếp chịu trách nhiệm cung cấp nhân chứng theo yêu cầu của người dùng và tính phí dịch vụ cho người dùng. Không giống như người dùng, các bộ chuyển tiếp có thể tập trung các dịch vụ vào một phân đoạn duy nhất; tuy nhiên, các bộ chuyển tiếp không thể dự đoán khi nào người dùng cần trạng thái, vì vậy họ phải đảm bảo rằng các nhân chứng được cập nhật kịp thời, nghĩa là trạng thái lưu trữ thời gian thực (được gọi là nhà cung cấp trạng thái) cho người dùng để có được.
tiêu đề phụ
Mạng chuyển tiếp và đề xuất thị trường phí
Không gian thiết kế của Ethereum 2.0 Giai đoạn 2 là rất lớn và đã có nhiều đề xuất cho các chế độ thực thi. Mỗi đề xuất thể hiện cách chuyển giao dịch giữa người dùng và khối người đề xuất tốt hơn thông qua thanh toán, kết hợp với cơ chế mạng chuyển tiếp. Chương này sẽ tóm tắt các giao thức khác nhau một cách ngắn gọn và dễ hiểu nhất có thể, đồng thời tập trung phân tích những điểm giống và khác nhau của chúng trong mạng chuyển tiếp và cơ chế tính phí.
Đề xuất đối chiếu (không dùng nữa)
Đây là một đề xuất ban đầu của Giai đoạn 2, chia khối xây dựng của chuỗi phân đoạn thành ba phần: người đề xuất, người đối chiếu và người thực thi. Một số người đề xuất chịu trách nhiệm thu thập các giao dịch và đóng gói chúng thành các khối (còn gọi là đối chiếu), một số người đề xuất chịu trách nhiệm gửi các đối chiếu vào chuỗi (biến chúng thành các khối) và cuối cùng, người thực thi đưa ra một trạng thái gốc mới dựa trên đối chiếu được đề xuất .
Đề xuất này chưa bao giờ được nghiên cứu đầy đủ, do đó, cũng không có nghiên cứu nào về cơ chế thanh toán phí. Ngoài các yếu tố khác, đề xuất này đã bị loại bỏ vì cơ chế khuyến khích của nó khuyến khích người dùng trở thành người đề xuất, đối tác và người thực hiện cùng một lúc để tối đa hóa lợi ích.
Phase 1 and Done
Casey Detrio đã nhấn mạnh trong bài đăng trên blog tiên phong của mình "Phase 1 and Done: Data Availability Engine-Ethereum 2.0": Trong giai đoạn 1, càng ít đoạn thực thi càng tốt có thể được thêm vào để kết nối dữ liệu mà không cần trạng thái phân mảnh. Trong sơ đồ này, các phân đoạn có thể thực hiện hai việc: 1) xác thực dữ liệu (nghĩa là chèn một loạt giao dịch vào cấu trúc dữ liệu được công nhận, chẳng hạn như cây Merkle); 2) thực hiện các hoạt động phi trạng thái đơn giản như xác thực bằng chứng Zero-knowledge cho dữ liệu bị xử phạt.
Trình xử lý khối dữ liệu có thể được xác định bằng cách tải hợp đồng lên chuỗi đèn hiệu (hợp đồng sẽ được chuyển đổi thành "tiền biên dịch" trong tương lai và sau đó trở thành "môi trường thực thi"). Hình thức của hợp đồng có thể là Mã byte có thể được phân tích cú pháp bởi khách hàng phụ thuộc vào nội dung của toàn bộ giao thức.
"Giai đoạn 1 và Hoàn thành" bỏ qua hầu hết các câu hỏi về cơ chế thanh toán phí, bởi vì vấn đề về cơ chế thanh toán đã tồn tại trong các đề xuất trước đó và sẽ tiếp tục tồn tại, vì vậy, thay vào đó, đề xuất cố gắng xác định nó là việc sử dụng lâu dài của Eth2 .0. Những thay đổi tối thiểu cần thực hiện và hy vọng sẽ sớm tìm ra. Một gợi ý khác là trả phí thông qua các hợp đồng trên Ethereum 1.x (người đề xuất khối cung cấp các khối dữ liệu đã xử lý và có sẵn trên Ethereum 2.0, sau đó chúng tôi trả tiền cho người đề xuất); tuy nhiên, điều này là đáng nghi ngờ vì nó sẽ khiến khả năng sử dụng của Ethereum 2.0 phụ thuộc rất nhiều vào trên Ethereum 1.x.
Phase 2 Proposal 1
Theo nghiên cứu của Detrio, Vitalik Buterin đã đưa ra một đề xuất mới cụ thể cho Giai đoạn 2: đề xuất giai đoạn 2 1. Trong đề xuất này, tập lệnh thực thi (ban đầu được gọi là "hợp đồng chuỗi đèn hiệu") được lưu trữ trên chuỗi đèn hiệu và ETH có thể được gửi vào tập lệnh thực thi (để trả phí) và nó sẽ không bao giờ rời khỏi chuỗi đèn hiệu; trạng thái và việc thực thi của từng phân đoạn là hoàn toàn độc lập.
Lưu ý rằng tên của chúng có thể gây hiểu lầm - tập lệnh thực thi là quy tắc xác định máy ảo thực hiện giao dịch, không phải hợp đồng thông minh mà chúng ta thấy trong Ethereum ngày nay. Các tập lệnh thực thi phải xác định các mô hình dữ liệu và opcode theo cách mà khách hàng có thể phân tích cú pháp, đo lường và mã hóa (chẳng hạn như mã ewasm).
Để thanh toán phí, mỗi tập lệnh thực thi về cơ bản là một hệ thống lớp 2 và người xác minh không thể "biết" cơ chế thanh toán nội bộ của nó. Đây không phải là lỗi thiết kế, mà là cố ý; nếu người xác minh phân đoạn được yêu cầu phân tích và tính toán các cơ chế phí khác nhau (có thể liên quan đến các loại tiền tệ khác nhau), điều này chắc chắn sẽ dẫn đến sự gia tăng đáng kể độ khó thực hiện và sự phức tạp của cơ chế kinh tế , đưa ra nhiều Điểm yếu hơn có thể bị khai thác hoặc thậm chí hoàn toàn không sử dụng được. Ở một mức độ lớn, các lập luận chống lại "sự trừu tượng hóa kinh tế" cũng có thể được sử dụng để chống lại loại mô hình thực thi xác định các loại phí theo kịch bản (Ghi chú của người dịch: "Trừu tượng hóa kinh tế" còn được gọi là "Khái quát hóa phí", trong The lớp giao thức hỗ trợ người dùng và người xác minh tùy chỉnh mã thông báo nào được sử dụng để trả phí xử lý. Một số người cho rằng điều này sẽ làm cho mã thông báo gốc mất giá trị).
Vì người xác thực không thể trực tiếp thu phí từ việc thực thi tập lệnh, nên họ phải thu phí dịch vụ thông qua các phương tiện khác. Điều này được thực hiện với một tập lệnh thực thi đặc biệt (tức là loại được lưu giữ); bất kỳ ai cũng có thể gửi một giao dịch có chứa logic sau: "Nếu dữ liệu này sử dụng một tập lệnh thực thi nhất định được đóng gói trong một khoảng thời gian nhất định trong một phân đoạn nhất định, thì tôi phải trả khoản tiền này phí cho người đã ghi lại khối dữ liệu này"; các thao tác ở đây đều được thực hiện bởi các bộ chuyển tiếp (còn được gọi là người vận hành): các bộ chuyển tiếp chịu trách nhiệm thu thập các giao dịch của người dùng, được chỉ định theo các tập lệnh thực thi chung không được lưu giữ. Phí được tính theo các quy tắc và sau đó người đề xuất khối (trình tạo) trong phân đoạn được thanh toán cho giao dịch được đóng gói theo tập lệnh thực thi được lưu giữ.
Blog của William Villanueva Hành trình qua Giai đoạn 2 của Ethereum 2.0 đưa ra một bản tóm tắt hoàn hảo về các đề xuất của Giai đoạn 2 cho đến nay.
Phase 2 Proposal 2
Lấy cảm hứng từ công việc trước đây của Detrio, V God một lần nữa đề xuất Đề xuất Giai đoạn 2 2, nhằm mục đích đơn giản hóa Đề xuất 1, loại bỏ trạng thái trên chuỗi phân đoạn và sử dụng chuỗi đèn hiệu để theo dõi các phân đoạn và môi trường thực thi khác nhau (Môi trường thực thi, EE, trước đây được gọi là Tập lệnh thực thi) gốc trạng thái khác nhau.
Ưu điểm của thiết kế này là các môi trường thực thi khác nhau có thể chọn bộ tích lũy của riêng chúng (ví dụ: cây Merkle thưa thớt, cây đỏ đen, bộ tích lũy mật mã, v.v.), không giống như đề xuất trước đó, phải tôn trọng (lưu giữ) Một dạng bộ tích lũy .
Bây giờ, quy trình giao dịch chung như sau: người dùng tạo giao dịch và gửi giao dịch đó đến người chuyển tiếp, người này sẽ thêm nhân chứng (dưới dạng nhánh Merkle nếu sử dụng bộ tích lũy Merkle) vì người dùng cần được người dùng thanh toán. Sau đó, người chuyển tiếp đóng gói nhiều giao dịch và cùng nhau gửi chúng đến người đề xuất khối, đồng thời thanh toán cho họ thông qua cơ chế tích hợp sẵn của giao thức, cho phép người đề xuất đóng gói lô giao dịch vào khối (phân đoạn) tiếp theo. Giống như Đề xuất 1, "cơ chế được tích hợp trong giao thức" ở đây đề cập đến EE cao hơn (EE được ghi nhận), có thể được nhận ra bởi tất cả những người xác minh.
Đối với người xác minh, chương trình này giảm bớt gánh nặng của họ ở một mức độ nhất định, nhưng do các hoạt động trên vẫn yêu cầu một số trạng thái bảo vệ và đề xuất không thiết kế cơ chế thanh toán phí trong giao thức giữa người dùng và người chuyển tiếp nên vẫn chưa giải quyết được toàn bộ vấn đề với mạng chuyển tiếp. Đầu tiên, việc sử dụng các phương tiện bên ngoài giao thức để thực hiện thanh toán sẽ làm suy yếu quyền riêng tư của người dùng; thứ hai, không rõ cách tạo một hệ thống hoàn toàn ngoài chuỗi (không phụ thuộc vào một chuỗi khối bên ngoài khác) để đảm bảo rằng người dùng và người chuyển tiếp có sự đồng thuận -tay Tiền được giao bằng một tay (nghĩa là tính nguyên tử của giao dịch); thứ ba, rủi ro cao tiềm ẩn khi sử dụng các phương tiện ngoài thỏa thuận để thanh toán và khả năng tính toán cao cần thiết để trở thành người chuyển tiếp (bởi vì nếu chuyển tiếp muốn phục vụ EE hoặc phân đoạn, tất cả trạng thái của chúng phải được lưu trữ để có thể tạo nhân chứng), có thể dẫn đến các vấn đề về tập trung - trong trường hợp xấu nhất, có thể chỉ còn lại một vài rơle "người gác cổng" giữa người dùng và mạng Ethereum 2.0 Bởi.
Quay lại chế độ nhóm bộ đệm giao dịch
Vitalik đã đề cập trong đề xuất mới rằng việc cho phép những người chuyển tiếp thanh toán có điều kiện cho những người đề xuất khối yêu cầu một phương pháp cam kết kép nặng nề để đảm bảo tính nguyên tử của khoản thanh toán. Trong đề xuất này, EE sẽ có số dư riêng. Sau khi EE thực hiện một loạt giao dịch, nó sẽ xuất ra biên lai và EE cấp cao (EE được lưu giữ) chịu trách nhiệm thanh toán phí sẽ chuyển Ethereum từ tài khoản EE sang người đề xuất khối dựa trên dữ liệu này. Do đó, EE trả phí cao hơn có thể "xem lại" biên lai trước đó và xử lý chuyển khoản. Việc nạp tiền vào tài khoản EE có thể là trách nhiệm của người chuyển tiếp (hoặc các bên liên quan khác).
Ưu điểm của đề xuất này là không cần sử dụng bất kỳ phương thức phức tạp nào để phối hợp thanh toán giữa người chuyển tiếp và người đề xuất khối, nhưng nó không chỉ định cách người dùng nên tương tác với người chuyển tiếp mà chỉ khuyến nghị sử dụng các kênh thanh toán .
Dựa trên đề xuất ban đầu, Villanueva đề xuất quay lại mô hình vùng đệm giao dịch. Trong trường hợp này, người chuyển tiếp chỉ cần đóng vai trò là nhà cung cấp trạng thái, chỉ cung cấp nhân chứng mà không đóng gói giao dịch; người đề xuất khối (hoặc tổng quát hơn, trình xác nhận phân đoạn) duy trì vùng đệm và dữ liệu nhân chứng cần thiết để đóng gói giao dịch. Vì mỗi EE có thể chọn các bộ tích lũy khác nhau, nên EE phải khai báo trước một phương pháp cố định để hợp nhất các nhân chứng, để những người đề xuất khối có thể tích hợp hai hoặc nhiều nhân chứng, chẳng hạn như tích hợp nhiều nhánh Merkle thành một đa chứng minh Merkle.
Vì nhà cung cấp trạng thái chỉ cần cung cấp nhân chứng (thường ở dạng nhánh Merkle), nhiều vai trò đã có sẵn cho nhiệm vụ này: ví dụ: máy chủ máy khách nhẹ. Nhiều máy chủ light-client hơn có thể được khuyến khích cung cấp cho nhân chứng những công cụ thuận tiện hơn và chi phí thấp hơn, điều này có thể giúp ích rất nhiều cho độ tin cậy cao. Tuy nhiên, người dùng vẫn phải đau đầu khi phải trả tiền cho các nhà cung cấp nhà nước bằng các kênh thanh toán có tính ma sát cao.
Kiến trúc thay thế giai đoạn 2
Cách đây không lâu, Vitalik đã đề xuất kiến trúc thay thế Giai đoạn 2, với ý định loại bỏ hoàn toàn trạng thái sharding. Điểm mấu chốt là một công cụ chuyển đổi trạng thái hoàn chỉnh, có trạng thái và biểu cảm (chẳng hạn như EVM) được thêm vào chuỗi báo hiệu. Công cụ này hoạt động như một "bộ lập lịch" theo dõi gốc trạng thái của EE. Thiết kế bộ lập lịch cũng cho phép thực hiện giao dịch nhiều phân đoạn: kiểm tra các phân đoạn và khe thời gian theo thứ tự định trước để đảm bảo rằng nhiều giao dịch trên các phân đoạn tới cùng EE được thực hiện chính xác (bằng cách kiểm tra trạng thái trước khi thực hiện và gốc trạng thái sau khi thực hiện , bỏ qua mọi khối phân đoạn không hợp lệ hoặc không đúng thứ tự).
Cơ chế thanh toán phí của đề xuất này không thay đổi so với đề xuất trước đó, nhưng vì người điều phối có đủ năng lực để xử lý việc quản lý số dư EE và tiêu thụ hóa đơn nên không cần phải có một khoản phí thanh toán EE cụ thể nữa.
Đề xuất đơn giản hóa chuỗi phân đoạn
Tại hội nghị DevCon 5, Vitalik đã công bố một đợt tái cấu trúc lớn đối với kiến trúc Ethereum 2.0, kiến trúc này được lấy cảm hứng từ thiết kế khối sharding của giao thức Near - Nightshade. Trong đề xuất mới, thay vì yêu cầu mỗi chuỗi phân đoạn chạy các quy tắc lựa chọn ngã ba độc lập, các khối và liên kết ngang được xen kẽ để tạo các khối và liên kết chéo với tốc độ nhanh hơn; các khối trong phân đoạn theo sau các khối chuỗi Beacon được tạo cùng nhau và tất cả các phân đoạn đều được liên kết chéo được kết nối với mọi khối chuỗi đèn hiệu (trong trường hợp bình thường). Kiến trúc tăng số lượng liên kết chéo phân đoạn. Để đáp ứng với sự gia tăng số lượng liên kết chéo, số lượng phân đoạn giảm từ 1024 xuống 64; đồng thời, thông lượng của mỗi phân đoạn cũng tăng lên, làm cho thông lượng của toàn bộ khối lượng hệ thống vẫn ở mức ban đầu.
Thay đổi cơ bản trong chế độ tư duy nêu trên làm cho thị trường phí trở nên đơn giản hơn: vì số lượng phân đoạn giảm đi đáng kể, giao tiếp giữa các phân đoạn được đơn giản hóa và người dùng có thể trực tiếp lưu trữ Ether trên mỗi phân đoạn và trực tiếp đề xuất thanh toán khối bởi người nhận ( một lần nữa thông qua đề xuất đã nói ở trên để xuất biên lai qua EE).
tiêu đề phụ
nhắc lại
Các cuộc thảo luận ở trên về mạng chuyển tiếp/thị trường phí trong Ethereum 2.0 là không đầy đủ:
Đối với người dùng, người chuyển tiếp và người đề xuất chặn, mọi người đều cần các dịch vụ và ưu đãi thanh toán phù hợp. Người dùng có thể nhận được các nhân chứng cần thiết bằng cách trả tiền, người chuyển tiếp tính phí cung cấp nhân chứng và chặn người đề xuất tính phí cho các giao dịch trọn gói. Cách người chuyển tiếp thanh toán cho người đề xuất khối (hoặc gián tiếp thông qua EE) có thể được khai báo trong thỏa thuận; nhưng người dùng muốn lấy dữ liệu nhân chứng trong khi đảm bảo rằng giao dịch được đóng gói và phương thức thanh toán không đơn giản như vậy.
Đối với người dùng, một phương thức thanh toán tốt phải ít ma sát, giúp họ dễ dàng chuyển đổi giữa các người chuyển tiếp khác nhau. Tuy nhiên, tùy thuộc vào kênh thanh toán của chuỗi khối bên ngoài, có các khoản tiền gửi thanh toán trước và các yêu cầu đối với sự tồn tại của chuỗi bên ngoài; lý tưởng nhất là vấn đề thanh toán của người dùng có thể được giải quyết trong thỏa thuận.
Tiếp tục từ điểm trước, nó sẽ gây khó khăn cho người chuyển tiếp trong việc kiểm duyệt người dùng. Thật không may, các nhân chứng được lấy từ danh sách truy cập được nhúng, vì vậy không có cách nào ngăn người chuyển tiếp đưa vào danh sách đen.
Người xác thực không cần phải "hiểu" các phương thức thanh toán bên trong mỗi EE, vì điều này sẽ cực kỳ phức tạp và là rào cản lớn đối với việc triển khai và thiết lập một thị trường hiệu quả.
Người dùng không bắt buộc phải duy trì các nút đầy đủ (ví dụ: họ không cần phải duy trì các nhân chứng mà họ cần). Chúng tôi muốn đề xuất này rất thân thiện với khách hàng nhẹ.
tóm tắt
tóm tắt
Nhìn lại năm vừa qua, một số lần lặp lại đã được thực hiện xung quanh nghiên cứu về mạng chuyển tiếp và thị trường phí.Chúng tôi cam kết mang lại trải nghiệm người dùng tốt cho người dùng và các nút nhẹ đồng thời giảm gánh nặng cho người xác minh và đảm bảo truy cập miễn phí truy cập càng nhiều tình dục càng tốt. Sắp tới, chúng tôi hy vọng sẽ thấy nhiều đề xuất hơn cho Giai đoạn 2, cải thiện hơn nữa và hoàn thiện tất cả các khía cạnh của Ethereum 2.0!
Ghi chú: Link nguyên văn:https://medium.com/
