Sơ đồ lộ trình phát triển của Ethereum

Nguồn | barnabe.substack.com

Tác giả | Barnabé Monnot

Phần sau đây được điều chỉnh từ một bài thuyết trình vào Thứ Sáu, ngày 9 tháng Tư

Bài viết này nói về con đường dẫn đến tương lai của Ethereum. Nhóm nhà phát triển Eth2 gọi Ethereum hiện tại là "eth1", hiện được gọi là chuỗi PoW. Và Ethereum trong tương lai không phải là eth1 hay eth2, mà là...Ethereum:

Mô tả hình ảnh

chữ

Mô tả hình ảnh

Hình: Cơ chế PoS thay thế cơ chế PoW

PoW không hoàn toàn tệ, nhưng tôi cần một tiêu đề hấp dẫn

PoW yêu cầu rất nhiều phần cứng để chạy các tính toán chuyên sâu, dẫn đến tiêu thụ năng lượng quá mức. Chúng tôi không nói về sự lãng phí tài nguyên giống như hầu hết các nhà phê bình tiền điện tử (luận điệu thông thường của họ là "tại sao chúng ta nên sử dụng hệ thống thanh toán tiêu tốn tài nguyên quốc gia?"), điều chúng tôi ủng hộ là vì chúng ta có thể trả mức tiêu thụ tương đối nhỏ để làm điều tương tự , thì chúng ta nên làm như vậy.

Mô tả hình ảnh

Hình: Nếu không xác minh bước 2 sẽ bị mất tài sản

Mô tả hình ảnh

chữ

Lớp đồng thuận đảm bảo rằng mọi người đồng ý về một phần dữ liệu chính xác nhất định. Và lớp thực thi thực sự diễn giải dữ liệu này cho hợp lý. "Dữ liệu" là bất kỳ hình thức tương tác nào với chuỗi khối, chẳng hạn như triển khai hợp đồng, thực hiện giao dịch trên sàn giao dịch, gửi giao dịch thanh toán, v.v...

Về cốt lõi, một chuỗi khối là về việc thêm các khối mới vào chuỗi. Khi một khối mới được thêm vào, trạng thái trước khối sẽ chuyển sang trạng thái sau khối. Trạng thái này tổng hợp tất cả dữ liệu từ các khối 0 đến N.

Mô tả hình ảnh

Bước đầu tiên là tách lớp đồng thuận khỏi lớp thực thi; bước thứ hai là chuyển từ PoW sang PoS

Mô tả hình ảnh

Hình: Bước đầu tiên đã hoàn thành

Kể từ tháng 12 năm 2020, chúng tôi có hai chuỗi hoạt động cùng lúc:

➤ Đầu tiên là chuỗi đồng thuận PoS (còn được gọi là chuỗi đèn hiệu)

➤ Thứ hai là chuỗi thực thi + đồng thuận PoW đáng tin cậy của chúng tôi (hay còn gọi là eth1)

Mô tả hình ảnh

Hình: Cách trở thành người xác thực

Mô tả hình ảnh

Hình: Hợp nhất

Hy vọng rằng tình trạng mất khả năng giao tiếp này sẽ không kéo dài quá lâu. "Hợp nhất" kết nối vĩnh viễn chuỗi đồng thuận PoS và chuỗi đồng thuận PoW+thực thi, có nghĩa là trình xác thực có thể tạo khối cho lớp thực thi. Sau khi sáp nhập, chúng tôi có hai loại chuỗi:

➤ Chuỗi đồng thuận PoS

➤ Chuỗi thực thi dựa trên PoS (tức là chuỗi "eth1")

Sau khi sáp nhập, những người xác thực của chuỗi đồng thuận PoS sẽ có thể đổi và rút tiền đặt cọc cũng như phần thưởng của họ và gửi chúng trở lại chuỗi thực thi dựa trên PoS. [2]

Mô tả hình ảnh

Mô tả hình ảnh

(Tóm tắt màu: đồng thuận=tím, thực thi=xanh lục, dữ liệu=vàng)

Nói về tổng số, đây là một trong nhiều giải pháp mở rộng có sẵn, nhưng từ quan điểm thiết kế giao thức, giải pháp này có thể mang lại sự thỏa hiệp tối ưu. Ý tưởng của sơ đồ này rất đơn giản: xử lý các chuyển đổi trạng thái một cách tổng hợp bằng cách lưu trữ dữ liệu trên chuỗi (được sử dụng để tái cấu trúc việc thực hiện các chuyển đổi trạng thái) và đưa việc thực thi trạng thái ra khỏi chuỗi. Nếu ai đó không đồng ý với kết quả của việc thực thi hoặc nếu ai đó quên thực thi nó ngay từ đầu, thì dữ liệu sẽ được lưu trữ trên chuỗi và có sẵn cho mọi người (và có thể được tính toán lại), hoàn toàn không cần cấp phép!

Mô tả hình ảnh

Hình: Một số giải pháp tổng số đã được triển khai và nhiều giải pháp khác đang được phát triển

Người dùng cần đi đến chuỗi thực thi ("eth1"Hợp đồng rollup trên ) cam kết một tài sản để có thể tham gia rollup, nơi người dùng có thể giao dịch. Sau khi hoàn tất, người dùng có thể chuyển nội dung từ tổng số trở lại chuỗi thực thi.

Các lựa chọn thay thế cho Rollup là gì? Hãy nhìn vào bức tranh trên, hãy tưởng tượng, nếu chúng ta thay thế những chuỗi màu vàng thẳng đứng đó bằng một chuỗi chuỗi màu đỏ song song thì sao? Ví dụ: điều gì sẽ xảy ra nếu chúng tôi sao chép một số chuỗi eth1 và chạy chúng cạnh nhau?

Vấn đề ở đây là làm thế nào để xử lý nhiều chuỗi thực thi chạy song song. Điều gì sẽ xảy ra nếu có điều gì đó xảy ra trên một chuỗi và những chuỗi khác cần biết? Đây là một vấn đề rất khó đối với sharding hoặc một vấn đề cần được khắc phục đối với các kế hoạch được thực hiện trong nhiều chuỗi.

"Không có sự khác biệt giữa Rollup", người đọc có thể nghĩ như vậy, không có gì sai với điều này. Nhưng khi bạn muốn chuyển từ một danh sách tổng hợp này sang một danh sách tổng hợp khác, vấn đề rắc rối tương tự lại phát sinh. Tuy nhiên, vấn đề là một số thiết kế tổng số đã tồn tại và không gian có thể khám phá cho các giải pháp này vẫn còn rất rộng. Trong trường hợp đó, tại sao không thử nghiệm các bản tổng hợp trước, sau đó giới thiệu một cách tiếp cận ở cấp độ giao thức?

Mô tả hình ảnh

Hình: Sử dụng phân đoạn để lưu trữ dữ liệu do tổng số xuất bản

Độc giả hẳn đã nghe nói về không gian khối không đủ, phải không? Các bản tổng hợp cần xuất bản dữ liệu của họ, nhưng không gian khối eth1 rất khan hiếm! Ngoài ra, như chúng ta đã thảo luận, cross-sharding rất khó. Để giải quyết vấn đề này, chúng ta có thể sử dụng tính năng phân mảnh để lưu dữ liệu mà tổng số cần phát hành. Tại thời điểm đó, có khả năng sẽ có 64 phân đoạn hoặc gấp 64 lần băng thông hiện có. Và một khối phân đoạn có thể chứa nhiều dữ liệu hơn khối chuỗi eth1 hiện có thể chứa.

Mô tả hình ảnh

Hình: Mỗi rollup có môi trường thực thi riêng

Vẫn còn rất nhiều việc phải làm trong lĩnh vực này! Trước hết, đừng quên rằng cả "hợp nhất" và "phân mảnh dữ liệu" đều là những nhiệm vụ rất phức tạp yêu cầu nhiều nhóm làm việc trên một hoặc cả hai nhiệm vụ cùng một lúc. Nhưng về rollup thì vẫn còn một số vấn đề thú vị cần tìm hiểu, mình chỉ liệt kê một số thôi:

➤ Cho phép di chuyển hàng loạt giữa người dùng và tổng số là một khái niệm thú vị. Nếu người dùng có đủ phương tiện giao thông công cộng để đưa họ qua lại giữa Lớp 1 (eth1) và Lớp 2 (bản tổng hợp), tại sao họ phải tự lái xe qua lại? Điều này là rất không kinh tế.

➤ Nếu người dùng nghĩ rằng anh ta có thể làm một số điều thú vị trong một bản tổng hợp khác (bản tổng hợp mà anh ta tham gia không tồn tại), anh ta có phải rút tiền về L1 trước, sau đó gửi tiền vào bản tổng hợp này từ L1 không? Điều này là quá lãng phí.

➤ Không còn nghi ngờ gì nữa, các bản tổng hợp giúp tăng đáng kể băng thông mạng cho các hoạt động trên chuỗi hiện tại. Nhưng các bản tổng hợp vẫn không phải là đường cao tốc vô tận mà người dùng mong đợi. Vẫn có nhiều người muốn làm nhiều việc trong danh sách, đôi khi cùng một lúc! Do đó, các bản tổng hợp chắc chắn sẽ gặp phải vấn đề tắc nghẽn, nhưng không giống như L1, một thị trường đặc biệt tắc nghẽn (1559 sẽ sớm ra mắt), không gian có thể khám phá của các bản tổng hợp rộng hơn.

➤ Nói về tắc nghẽn, mặc dù điều này cụ thể hơn đối với cấp độ giao thức, nhưng chúng ta cũng sẽ thấy EIP-1559 hoạt động như một cảnh sát giao thông để chỉ định lượng dữ liệu được xuất bản trên mỗi phân đoạn, đảm bảo trình xác thực có thể xử lý lượng dữ liệu đó. Nếu bạn cho rằng việc chạy EIP-1559 trên eth1 là tuyệt vời, hãy chờ đợi để chạy 1559 trên tất cả 64 chuỗi phân đoạn cùng một lúc. Vì vậy, các bản tổng hợp nên xuất bản dữ liệu của họ ở đâu? Có phải nó chỉ được xuất bản trên một phân đoạn duy nhất để dữ liệu chỉ khả dụng trên phân đoạn đó không? Hay nó được xuất bản trên nhiều phân đoạn để có thể hưởng lợi từ kế hoạch "phân mảnh đáng kinh ngạc" đã lên kế hoạch? Giải pháp này do Vitalik đề xuất, nghĩa là các phân đoạn thay phiên nhau tạo ra các khối, để khi xuất bản dữ liệu, thời gian từ khi tạo các khối mới chỉ trong vòng vài trăm mili giây, lý tưởng cho các ứng dụng yêu cầu "hoàn thiện nhanh".

Đặc biệt cảm ơn Danny Ryan và Sacha Saint-Leger vì những gợi ý của họ.

[1] Tôi nghe nói rằng PoW không phải là một thuật toán đồng thuận, nhưng tôi nghĩ sẽ ổn nếu mô tả nó như một cơ chế đồng thuận nếu nó làm quá tải định nghĩa của nó.

[2] PhiGo đã viết trên Twitter rằng sau khi sáp nhập (PoW thoát khỏi Ethereum), không nhất thiết phải rút tiền gửi đã cam kết. Đúng là hiện tại chương trình sáp nhập tập trung nhiều hơn vào phần sáp nhập, trong khi vấn đề "rút lui" là một nỗ lực nghiên cứu riêng biệt nhưng có liên quan.