Ý kiến: Eth2 là công cụ cung cấp dữ liệu

Đọc bài viết này mất 24 phút

Tác giả dự định đề xuất một giải pháp thay thế cho lộ trình Giai đoạn 2 cho Eth2.0, tức là liệu hệ thống như vậy có hữu ích hay không nếu sharding chỉ được sử dụng để đảm bảo tính khả dụng của dữ liệu.

Tiêu đề gốc: "Xem | Giai đoạn một và đã hoàn thành: Eth2 như một công cụ cung cấp dữ liệu"

Nguồn gốc: Những người đam mê Ethereum

Ghi chú của người biên tập: Tiêu đề ban đầu của bài viết này là "Giai đoạn một và hoàn thành: eth2 như một công cụ sẵn có dữ liệu". Tại thời điểm xuất bản (tháng 4 năm 2019), tác giả dự định cung cấp Eth2 .0 đề xuất lộ trình thay thế Giai đoạn 2, nghĩa là, nếu sharding chỉ được sử dụng để đảm bảo tính khả dụng của dữ liệu, thì hệ thống đó có hữu ích không và những phần nào cần được thêm vào để nó trở nên hữu ích. Đáng ngạc nhiên là cách đây một năm rưỡi, tác giả đã nhận ra rằng đối với một hệ thống như zk-rollup, điều mà lớp dưới cùng phải đảm bảo là "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 bị ràng buộc về mặt nguyên tử. "Cùng nhau", vì vậy lớp dưới cùng phải có khả năng thực thi, thậm chí thực thi không trạng thái rất đơn giản và (tác giả cũng chỉ ra thông qua lý luận từng lớp) để đảm bảo trải nghiệm người dùng, điều còn thiếu chính là thủ tục tải dữ liệu lên phân đoạn Thanh toán phí thống nhất (hai quan điểm hiểu biết này, thậm chí cho đến ngày nay, vẫn được coi là tiên tiến, thậm chí tiên tiến). Giao thức tính phí xử lý 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, thành viên của nhóm Ewasm và đã đưa ra nhiều ý tưởng cho Giai đoạn 2 trước đây; anh ấy cũng tin rằng Eth2.0 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 thực thi như bình thường khi Eth2 xuất hiện”. Anh ấy là một nhà phát triển bị đánh giá thấp.

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

Tuy nhiên, từ góc độ của Eth1.x, Eth1.x muốn thực hiện những điều chỉnh lớn về chi phí của hai loại tài nguyên: lưu trữ và dữ liệu giao dịch (tx dữ liệu). 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 khuyến khích các nhà phát triển dApp sử dụng bộ nhớ nhiều hơn dữ liệu giao dịch khi viết hợp đồng, khiến việc lưu trữ trở thành nút thắ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. Sau 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ữ (tức là họ sẽ viết nhiều hợp đồng không trạng thái hơn là 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 dự kiến 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 giả sử thông lượng bị giới hạn bởi dữ liệu giao dịch thì để mở rộng quy mô Ethereum, các phân đoạn trên Serenity không cần phải có trạng thái. Nếu thông lượng bị giới hạn bởi dữ liệu giao dịch đến 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 lên gấp 1000.

Điều này nghe có vẻ hay nhưng nó cần được triển khai thông qua sharding, dự kiến phải đợi đến Giai đoạn 2. Trong thời gian chờ đợi, chúng tôi 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ụ sẵn có 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 Eth2 một cách hiệu quả như một nhà cung cấp 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 đồng thời trong quá trình thực thi (tức là xác minh bằng chứng SNARK và cập nhật gốc trạng thái), bạn sẽ kết thúc với 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ẽ gây ra những đánh đổi phức tạp và cần phải giải quyết những thách thức của người vận hành cũng như cơ chế thoát ra như plasma. Trong thách thức về tính khả dụng, bất kỳ ai cũng có thể cung cấp dữ liệu để chứng minh tính khả dụng, vì vậy không rõ liệu việc đưa dữ liệu vào phân đoạn Eth2 bắc cầu có giúp mọi việc dễ dàng hơn hay không.

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

Có lẽ chúng ta không nên ngạc nhiên trước nhận thức này. Nếu chỉ tính sẵn có của dữ liệu (không thực thi) là hữu ích, thì sẽ không ai nói 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 0 (đối tượng lớn nhị phân) và sẽ không ai phàn nàn về việc phải đợi Eth2 đến tham gia Giai đoạn tiếp theo là lúc nó 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à một 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à, chúng ta có thể xây dựng Mastercoin 2.0!)

Vậy tại sao Giai đoạn 1 lại xung đột với việc thực thi? Chà, giả sử việc thực thi có trạng thái, mỗi phân đoạn sẽ duy trì một số trạng thái cục bộ. Nếu trình xác thực cần duy trì nhiều trạng thái cục bộ, việc xáo trộn trình xác nhận sẽ phức tạp hơn nhiều. Mặt khác, nếu không thực thi thì không cần phải lo lắng về trạng thái cục bộ. Việc xáo trộn trình xác thực sẽ đơn giản hơn nhiều và chúng ta có thể tập trung vào việc xây dựng các phân đoạn bằng cách sử dụng các đốm màu dữ liệu và bắt đầu 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 cố gắng thực hiện việc này bằng 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 beacon: code, stateRoot và đã triển khaiShardId. Ngoài ra còn có hàm process_deploy (ngay bên dưới process_transfer). Sau khi mã được triển khai, người xác thực 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ị hủy và mã sẽ được triển khai vĩnh viễn].

Bây giờ, chúng tôi giả định 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 thực hiện việc này như thế nào? Theo những gì tôi biết, làm thế nào để quyết định gói dữ liệu nào vào khối phân đoạn vẫn là một câu hỏi mở đối với người xác thực phân đoạn giai đoạn 1. Giả sử điều này không được nêu chi tiết trong đặc tả giai đoạn 1. Sau đó, đối với người dùng, nếu họ muốn đóng gói các đốm dữ liệu của mình vào phân đoạn, chỉ có hai cách: (1) Liên hệ với người xác thực và gửi yêu cầu đến phân đoạn thông qua phương thức bên ngoài giao thức (ví dụ: kênh thanh toán eth1) Khoản thanh toán của nó; (2) việc tự mình trở thành người xác thực có thể đóng gói các đốm màu dữ liệu vào các phân đoạn (khi chúng được chọn ngẫu nhiên làm người đề xuất khối cho các phân đoạn). Cả hai phương pháp này đều là những lựa chọn tồi.

Một cách tiếp cận tốt hơn là đặt vấn đề lên bàn thảo và cho phép người xác thực thanh toán phí cho người đề xuất khối hiện tại thông qua giao thức giao dịch. Đổi lại, người đề xuất khối sẽ đóng gói blob dữ liệu của người xác nhận vào chuỗi phân đoạn. Tuy nhiên, cách tiếp cận này không hiệu quả nếu có yêu cầu về năng lực tối thiểu đối với các hoạt động của khối chuỗi beacon (chẳng hạn như chuyển trình xác nhận). Nếu không có giao thức giao dịch cho phép người xác thực quyết định mức độ ưu tiên của việc đóng gói blob dữ liệu, trường hợp sử dụng "giai đoạn 1 làm công cụ sẵn có dữ liệu" sẽ không được thực hiện (cho dù đó là hợp đồng eth1 được kết nối với chuỗi đèn hiệu thông qua cầu nối 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 đã từng nghe nói đến trước đây). Dù sao đi nữa, hãy giả sử rằng cho dù người đề xuất sharding đóng gói các khối dữ liệu trong chế độ "công cụ sẵn sàng dữ liệu mà không thực thi" như thế nào thì việc đó cũng có thể được thực hiện trong chế độ "công cụ sẵn sàng dữ liệu với thực thi không trạng thái đơn giản".

Được rồi, giả sử rằng một blob dữ liệu cụ thể có thể được đóng gói thành một khối. Mỗi khối giới hạn việc thực thi ở một giao dịch (ví dụ: toàn bộ blob dữ liệu phải phục vụ như một giao dịch). Chúng tôi vẫn chưa làm rõ giao dịch nên 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ử trường hợp sau và mã thực hiện kiểm tra chữ ký của riêng 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í nên không có giá gas và opcode GASPAY). Nếu blob được giải mã thành công dưới dạng giao dịch, mã tài khoản đích sẽ được thực thi với dữ liệu và trạng thái gốc 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 để cập nhật trạng tháiRoot của tài khoản người xác thực? Chúng tôi không thể cập nhật trạng thái gốc ở BeaconState (trạng thái chuỗi đèn hiệu) của mỗi khối phân đoạn (vì giới hạn nghiêm ngặt về số lượng hoạt động của chuỗi đèn hiệu). Tuy nhiên, trường phân mảnh ở trạng thái của chuỗi báo hiệu sẽ được cập nhật với liên kết chéo. Lấy gốc trạng thái đã 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ử chúng đã được băm và nhận shard_state_root (gốc trạng thái phân đoạn). shard_state_root có vẻ tương tự như 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 đó).

Không thể phủ nhận rằng không phải mọi gốc trạng thái phân đoạn đều được cập nhật mỗi khi khối chuỗi beacon được khai thác, vì vậy sẽ 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 trạng thái sẽ được giảm thiểu. Điều này tương tự với dữ liệu cần được chuyển giữa các trình xác thực trong quá trình xáo trộn một số khối phân đoạn.

Tất nhiên rất nhiều chi tiết bị bỏ qua ở đây. Điều tôi đang muốn nói là hầu hết các yêu cầu đối với việc thực thi không trạng thái dường như đã được đáp ứng trong giai đoạn 1. Tôi nghĩ vấn đề lớn nhất là vẫn chưa rõ cách 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 sẽ không phải là một công cụ sẵn có bắc cầu). Có thể đây 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 đã bỏ qua điều gì? 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 theo cách nào đó trong giai đoạn 1 (hoặc giai đoạn 1.1, nếu bạn muốn) là gì?

Chế độ thực thi này đơn giản hơn so với đề xuất giai đoạn 2. Một trong những lý do là tài khoản hợp đồng có tính toàn cầu, giống như tài khoản người xác thực. Điều này có nghĩa là số lượng tài khoản hợp đồng phải được giới hạn và chi phí triển khai mã cao bằng (hoặc có thể thấp hơn) chi phí để trở thành người xác thực. Nhưng chúng tôi có đồng ý với sự đánh đổi này không nếu điều này cho phép chúng tôi thực thi Eth2 nhanh hơn? Sau khi mã được triển khai, bộ nhớ hợp đồng không thể thay đổi, vì vậy có thể nói rằng chúng tôi đang cố gắng cung cấp khả năng thực thi cho Giai đoạn 1 mà không cần mở rộng bộ nhớ hợp đồng. Một trường hợp sử dụng quan trọng khác ở đây: thông lượng cực cao với tính khả dụng của dữ liệu (thông lượng giao dịch tăng 1000 lần).

Ngay cả với việc thực thi không trạng thái cơ bản, người dùng vẫn có thể thực hiện các lệnh gọi hợp đồng giữa các phân đoạn bằng cách gửi bằng chứng trạng thái của một hợp đồng dưới dạng dữ liệu giao dịch đến một hợp đồng khác. Các hợp đồng cũng có thể triển khai chức năng giống như biên nhận của riêng chúng (các biên nhận trong thư mục gốc trạng thái hợp đồng cũng có thể được xác minh như trường biên nhận trong tiêu đề khối). Trải nghiệm của nhà phát triển không tuyệt vời vì giao thức không cung cấp bất kỳ trợ giúp nào. Nhưng các đề xuất giai đoạn 2 hiện tại dường như thiếu chức năng thực tế để tạo điều kiện cho tương tác hợp đồng giữa các phân đoạn (rắc rối xảy ra với các nhà phát triển dApp, những người phải triển khai logic nhận biên lai từ các phân đoạn khác nhau, đảm bảo biên lai không bị chi tiêu gấp đôi, v.v.) . Vì vậy, xét về mặt trải nghiệm của nhà phát triển, việc thực thi không trạng thái giai đoạn 1 cơ bản nghe có vẻ không tệ hơn nhiều so với ý tưởng giai đoạn 2 "đơn giản". Việc thực thi không trạng thái cơ bản cũng đủ để đạt được sự neo giữ hai chiều giữa BETH trên chuỗi beacon và ETH trên chuỗi chính.

Sự khác biệt lớn nhất giữa đề xuất Giai đoạn 2 và đề xuất của chúng tôi ở đây là mục tiêu của Giai đoạn 2 là mở rộng việc lưu trữ hợp đồng. Nhưng việc lưu trữ và do đó là thực thi trạng thái, dường như cũng là nơi bắt nguồn phần lớn sự phức tạp và là điều khiến chúng tôi không thể triển khai thực thi trong Giai đoạn 1.