Ý kiến: Eth2 với tư cách là Công cụ cung cấp dữ liệu

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)

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

, Tác giả: Casey Detrio, Người dịch & Người soát lỗi: Min Min & A Jian, được Odaily sao chép với sự cho phép.

Lưu ý của biên tập viên: Tiêu đề ban đầu của bài viết này là "Giai đoạn một và hoàn thành: eth2 dưới dạng công cụ cung cấp dữ liệu". Tại thời điểm xuất bản (tháng 4 năm 2019), tác giả dự định đề xuất lộ trình để Eth2.0 thay thế Giai đoạn 2 nghĩa là, nếu chỉ sử dụng sharding để đảm bảo tính khả dụng của dữ liệu, thì hệ thống như vậy có hữu ích không và cần bổ sung những phần nào để hệ thống trở nên hữu ích. Đáng ngạc nhiên, một năm rưỡi trước, tác giả đã nhận ra rằng đối với một hệ thống như zk-rollup, lớp dưới cùng phải đảm bảo rằng "việc thực hiện chuyển đổi trạng thái và tính khả dụng của dữ liệu phải được liên kết nguyên tử với nhau", vì vậy lớp bên dưới phải có khả năng thực thi, ngay cả khi nó là một thực thi phi trạng thái rất đơn giản; hơn nữa, (tác giả cũng đã chỉ ra thông qua các lớp suy luận) để đảm bảo trải nghiệm người dùng, phần chính vẫn còn thiếu là thủ tục về cách phân mảnh dữ liệu Phí thỏa thuận thanh toán (hai quan điểm này, thậm chí ngày nay, vẫn có thể được gọi là tiên tiến, thậm chí tiên tiến). Giao thức tính phí vẫn còn thiếu trong thông số kỹ thuật của Giai đoạn 2.

Nhân tiện, tác giả của bài viết này là Casey Detrio, một thành viên của nhóm Ewasm và đã cung cấp nhiều ý tưởng cho Giai đoạn 2 trước đây; ông cũng tin rằng Eth2 nên được thiết kế với cốt lõi là "đảm bảo rằng các hợp đồng Eth1 có thể được được thực thi như bình thường khi Eth2 đến".0. Anh ấy là một nhà phát triển bị đánh giá thấp.

Hiện tại, nút cổ chai hạn chế thông lượng Eth1 là sự tăng trưởng của nhà nước. Vì vậy, nếu chúng ta muốn mở rộng quy mô Ethereum, về mặt logic, 1000 phân đoạn với trạng thái độc lập có thể tăng thông lượng lên 1000 lần.

Tuy nhiên, từ lộ trình Eth1.x, Eth1.x muốn thực hiện những điều chỉnh lớn đối với chi phí của hai loại tài nguyên: lưu trữ (storage) và dữ liệu giao dịch (tx data). Hiện tại, dung lượng lưu trữ được định giá thấp và dữ liệu giao dịch được định giá quá cao. Điều này sẽ khuyến khích các nhà phát triển dApp sử dụng nhiều dung lượng lưu trữ hơn dữ liệu giao dịch khi viết hợp đồng, khiến dung lượng lưu trữ trở thành nút cổ chai thông lượng. Giải pháp được đề xuất cho vấn đề này là tăng giá lưu trữ và giảm giá dữ liệu giao dịch. Với những điều chỉnh chi phí này, các nhà phát triển sẽ được khuyến khích sử dụng dữ liệu giao dịch nhiều hơn là lưu trữ (nghĩa là họ sẽ viết nhiều hợp đồng không trạng thái hơn thay vì hợp đồng có trạng thái). Do đó, trong tương lai gần (nếu lộ trình Eth1.x được áp dụng rộng rãi), chúng tôi hy vọng thông lượng Eth1 sẽ bị giới hạn bởi dữ liệu giao dịch thay vì lưu trữ.

Nếu chúng tôi cho rằng thông lượng bị giới hạn bởi dữ liệu giao dịch, thì các phân đoạn trên Serenity không cần phải ở trạng thái để mở rộng quy mô Ethereum. Nếu thông lượng bị giới hạn bởi dữ liệu giao dịch từ các hợp đồng không trạng thái, thì 1000 phân đoạn không trạng thái sẽ tăng thông lượng theo hệ số 1000.

Điều này nghe có vẻ hay, nhưng nó cần được thực hiện thông qua sharding, dự kiến ​​sẽ đợi đến Giai đoạn 2. Đồng thời, chúng ta có thể sử dụng Giai đoạn 1 làm công cụ cung cấp dữ liệu. Thuật ngữ công cụ cung cấp dữ liệu dường như đang trở nên phổ biến. Hãy suy nghĩ về cách nó hoạt động.

Lấy zk-rollup làm ví dụ, zk-rollup bị giới hạn bởi tính khả dụng của dữ liệu. Hợp đồng zk-rollup trên Eth1 có thể sử dụng hiệu quả Eth2 làm nhà cung cấp đảm bảo tính khả dụng bắc cầu không? Nếu tính khả dụng của dữ liệu không thể được đảm bảo trong quá trình thực thi (nghĩa là xác minh bằng chứng SNARK và cập nhật trạng thái gốc), bạn sẽ nhận được một hệ thống zk-rollback giống như plasma. Mặc dù hệ thống này có thể cải thiện đáng kể TPS, nhưng nó sẽ đưa ra những đánh đổi phức tạp và cần phải đối phó với những thách thức của người vận hành và các cơ chế thoát như plasma. Trong một thách thức về tính khả dụng, bất kỳ ai cũng có thể đóng góp dữ liệu để chứng minh tính khả dụng, do đó, không rõ ràng rằng việc đưa dữ liệu vào phân đoạn Eth2 bắc cầu sẽ giúp mọi việc dễ dàng hơn.

Giờ đây với một phiên bản khác của zk-rollup, zk-rollup 500 TPS, mọi thứ đã dễ dàng hơn rất nhiều. Không còn cần người vận hành được chỉ định, bất kỳ ai cũng có thể đóng vai trò là người chuyển tiếp bất cứ lúc nào và tạo bằng chứng SNARK để cập nhật trạng thái. Trên thực tế, các đảm bảo về tính khả dụng của dữ liệu luôn đi kèm với các cập nhật trạng thái, điều đó có nghĩa là không cần phải đối phó với các thách thức của người vận hành và các cơ chế thoát như plasma. Nhưng điều này yêu cầu cả khả năng thực thi và tính khả dụng của dữ liệu phải xảy ra trong cùng một giao dịch, điều rất tiếc là chúng tôi không thể thực hiện được với công cụ tính khả dụng bắc cầu. Nói cách khác, bắc cầu là đủ cho hệ thống chứng minh gian lận như zk-rollback, nhưng không đủ cho hệ thống chứng minh tính hợp lệ như zk-rollup. Kết luận là để đơn giản hóa bằng chứng hợp lệ trên Lớp 2, một chức năng quan trọng mà công cụ khả dụng trên Lớp 1 cần phải có là đảm bảo rằng tính khả dụng của dữ liệu và việc thực hiện chuyển đổi trạng thái xảy ra đồng thời với nhau.

Có lẽ chúng ta không nên ngạc nhiên với nhận thức này. Nếu tính khả dụng của dữ liệu một mình (không có thực thi) là hữu ích, thì không ai có thể tranh luận rằng Giai đoạn 1 bắt đầu chỉ để đảm bảo tính khả dụng của một loạt các đốm màu khác không (đối tượng lớn nhị phân) và không ai sẽ phàn nàn về việc phải đợi Eth2 bước vào Giai đoạn tiếp theo sẽ thực sự phát huy tác dụng (ngoài PoS). Chúng tôi đang làm việc ở Giai đoạn 1 với tư cách là công cụ cung cấp dữ liệu, nhưng nó vẫn không làm được gì cả, vì vậy thật đáng thất vọng. (Ồ, chúng ta có thể xây dựng Mastercoin 2.0!)

Vậy tại sao Giai đoạn 1 xung đột với việc thực thi? Chà, giả sử thực thi có trạng thái, mỗi phân đoạn duy trì một số trạng thái cục bộ. Xáo trộn trình xác thực phức tạp hơn nhiều nếu trình xác thực cần duy trì nhiều trạng thái cục bộ. Ngược lại, nếu không thực hiện, đừng lo lắng về nhà nước địa phương. Việc xáo trộn trình xác thực sẽ đơn giản hơn nhiều, chúng tôi có thể tập trung vào việc xây dựng các phân đoạn bằng các đốm màu dữ liệu và bắt đầu các phân đoạn nhanh hơn.

Tuy nhiên, chúng ta đừng cho rằng việc thực thi là có trạng thái. Điều gì sẽ xảy ra nếu chúng ta thử làm điều đó với một máy ảo không trạng thái rất đơn giản?

Giả sử có 3 trường trình xác thực mới ở trạng thái chuỗi đèn hiệu: mã, trạng tháiRoot và DeployShardId. Ngoài ra còn có một chức năng process_deploy (ngay bên dưới process_transfer). Sau khi mã được triển khai, người xác minh phải đảm bảo rằng số dư tài khoản không giảm xuống dưới một ngưỡng nhất định [ít nhất 1 ETH bị khóa. Nếu không có chương trình tự hủy (SELFDESTRUCT) trong mã, thì phần ETH này tương đương với việc bị phá hủy và mã sẽ được triển khai vĩnh viễn].

Bây giờ, giả sử rằng đã có một số tài khoản có mã ở trạng thái chung.

Tiếp theo, chúng tôi cố gắng đóng gói các đốm màu dữ liệu cụ thể vào các phân đoạn, nhưng bằng cách nào? Theo những gì tôi biết, đây vẫn là một câu hỏi mở đối với những người xác thực phân đoạn giai đoạn 1 để quyết định các đốm màu dữ liệu nào sẽ đóng gói thành các khối phân đoạn. Giả sử điều này không được nêu chi tiết trong thông số kỹ thuật của giai đoạn 1. Sau đó, đối với người dùng, nếu họ muốn đóng gói các đốm màu dữ liệu của riêng họ thành các phân đoạn, chỉ có hai cách: (1) liên hệ với người xác minh và gửi đến khoản thanh toán của họ; (2) Tự mình trở thành người xác minh và bạn có thể (khi họ được chọn ngẫu nhiên làm người đề xuất khối của phân đoạn) đóng gói khối dữ liệu vào phân đoạn. Cả hai phương pháp này đều là những ý tưởng tồi.

Một cách tiếp cận tốt hơn là đưa mọi thứ vào bàn và cho phép những người xác nhận thanh toán cho người đề xuất khối hiện tại thông qua một thỏa thuận giao dịch. Đổi lại, người đề xuất khối đóng gói khối dữ liệu của người xác thực vào chuỗi phân đoạn. Tuy nhiên, cách tiếp cận này không hoạt động nếu các hoạt động của khối chuỗi đèn hiệu (chẳng hạn như chuyển trình xác thực) có yêu cầu về dung lượng tối thiểu. Trường hợp sử dụng "giai đoạn 1 làm công cụ cung cấp dữ liệu" sẽ không thể thực hiện được nếu không có giao thức giao dịch cho phép người xác thực ưu tiên đóng gói blob dữ liệu (cho dù đó là hợp đồng eth1 được kết nối qua cầu nối với chuỗi đèn hiệu hay Truebit, Mastercoin 2.0, hoặc các trường hợp sử dụng tính khả dụng của dữ liệu khác mà tôi đã nghe nói trước đây). Dù sao đi nữa, hãy giả sử rằng dù người đề xuất shard đóng gói các đốm màu dữ liệu trong chế độ "Data Availability Engine without Execution" như thế nào, nó cũng có thể ở chế độ "Data Availability Engine with Simple Stateless Execution".

Được rồi, giả sử rằng một số đốm màu dữ liệu nhất định có thể được đóng gói thành các khối. Mỗi khối hạn chế thực hiện một giao dịch (ví dụ: toàn bộ khối dữ liệu phải được đưa vào làm một giao dịch). Chúng tôi vẫn chưa làm rõ liệu giao dịch sẽ được ký bằng chìa khóa (có thỏa thuận giao dịch) hay không cần ký (không có thỏa thuận giao dịch). Giả sử cái sau và mã thực hiện kiểm tra chữ ký của chính nó (tương tự như trừu tượng hóa tài khoản; có giới hạn gas khối, nhưng không có cơ chế chuyển phí, do đó không có giá gas và không có opcode GASPAY). Nếu đốm màu có thể được giải mã thành công dưới dạng giao dịch, thì mã tài khoản đích sẽ được thực thi với dữ liệu và gốc trạng thái hiện tại làm đầu vào. Nếu thực thi thành công, dữ liệu trả về là trạng thái gốc mới.

Làm cách nào để chúng tôi cập nhật stateRoot của tài khoản trình xác thực? Chúng tôi không thể cập nhật gốc trạng thái trong BeaconState (trạng thái chuỗi đèn hiệu) của mỗi khối phân đoạn (vì số lượng hoạt động của chuỗi đèn hiệu bị hạn chế nghiêm ngặt). Tuy nhiên, trường phân mảnh ở trạng thái chuỗi đèn hiệu sẽ được cập nhật bằng liên kết chéo. Lấy gốc trạng thái được cập nhật của tất cả các tài khoản trên cùng một phân đoạn, giả sử rằng chúng được băm để lấy shard_state_root (gốc trạng thái phân đoạn). shard_state_root có vẻ giống với crosslink_data_root đã có trong thiết kế giai đoạn 1 (cả hai đều phụ thuộc vào hàm băm của nội dung khối phân đoạn trước đó).

Phải thừa nhận rằng không phải tất cả các gốc trạng thái phân đoạn đều được cập nhật mỗi khi khai thác một khối chuỗi đèn hiệu, vì vậy có một số trạng thái cục bộ. Tuy nhiên, nếu tài khoản là toàn cầu, dữ liệu gốc của trạng thái sẽ được giảm thiểu. Điều này tương tự như nhu cầu chuyển một số dữ liệu khối phân đoạn giữa các trình xác thực trong quá trình xáo trộn.

Tất nhiên, nhiều chi tiết được bỏ qua ở đây. Điều tôi đang cố gắng truyền đạt là hầu hết các yêu cầu đối với việc thực thi phi trạng thái dường như được đáp ứng trong giai đoạn 1. Theo tôi, vấn đề lớn nhất là vẫn chưa rõ làm thế nào người dùng có thể đóng gói các đốm màu của họ trên chuỗi (nếu vấn đề này không được giải quyết, giai đoạn 1 không thể là công cụ khả dụng cầu nối). Có lẽ đây mới chỉ là vấn đề đầu tiên, còn những vấn đề nghiêm trọng khác mà tôi đã bỏ qua. Tôi đang thiếu gì? Đâu là phần khó nhất khi cho phép người dùng đóng gói các đốm màu trên chuỗi trong giai đoạn 1 (hoặc giai đoạn 1.1, nếu bạn thích) bằng cách nào đó?