Tác giả gốc:Zhixiong Pan

Tác giả gốc:

Trong sự kiện "Hội nghị nâng cấp Ethereum Thượng Hải", chúng tôi đã mời bốn nhóm giải pháp mở rộng hoàn toàn khác nhau trong hệ sinh thái Ethereum để nói về công nghệ tiên tiến của Ethereum.

Đặc biệt là EOF và EIP-4844 có thể sẽ được đưa vào bản nâng cấp tiếp theo (Cancun). Ngoài ra, tường thuật về Sequencer phi tập trung và chuỗi khối mô-đun cũng là một hướng đi mới được các nhà nghiên cứu quan tâm hơn.

Bốn nhóm này có các tính năng nổi bật của riêng họ, chẳng hạn như tập trung vào lĩnh vực bằng chứng không kiến ​​thức (đặc biệt là zkEVM), tập trung vào WASM và mở rộng động, tập trung vào ngôn ngữ Move và mô đun hóa, đồng thời tập trung vào lưu trữ cho mục đích chung. Ngoài ra, chúng còn có rất nhiều điểm khác biệt ở các chi tiết kỹ thuật khác.

• Dorothy Liu from AltLayer

• Jolestar from Rooch Network

• Qi Zhou from EthStorage

• Ye Zhang from Scroll

TLDR

• Tham gia vào cuộc thảo luận này là:

• Việc nâng cấp EOF ít tác động hơn đến các nhà phát triển ứng dụng, nhưng có một số tác động đến Rollup và zkEVM. Có thể vẫn còn một số tranh cãi về việc liệu EOF có bước vào giai đoạn nâng cấp tiếp theo hay không.

• Một số giải pháp cho Sequencer phi tập trung: Byzantine Fault Tolerance (BFT), MEV Auction, Shared Sequencer (Flashbots), VDF, v.v. Ngoài ra, việc sắp xếp công bằng có thể không công bằng và các chiến lược khác nhau cần được áp dụng cho các ứng dụng.

• Mục đích của EIP-4844 không phải là để mở rộng dung lượng, mà hơn thế nữa là để hiện thực hóa một tập hợp các khái niệm cần thiết cho Danksharding trong tương lai, bao gồm Blob và Data Hash của nó. Triển khai các khái niệm này trước thời hạn để không cần phải nâng cấp hợp đồng khi triển khai Danksharding. EIP-4844 sẽ không mang lại những cải tiến đáng kể so với phương pháp chuỗi dữ liệu Ethereum hiện tại và băng thông mà chúng mang lại về cơ bản có cùng mức độ lớn.

Mọi người có quan điểm hoàn toàn khác nhau về chuỗi khối mô-đun: một số người cho rằng trong thời đại của các ứng dụng chất béo, cần cung cấp nhiều lựa chọn hơn; lớp dữ liệu là quan trọng nhất.

• Flashbots: The Future of MEV is SUAVE

• MEV Auction by Optimism

• Tarun Chitra: Ordering So Fair It Ain't Fair Ordering

• Keone: EIP-4844 Analysis of Optimism and Arbitrum

Tài liệu học tập Hardcore

Sau đây là toàn văn nội dung thảo luận, được OpenAI Whisper dịch và GPT-4 xử lý, có sửa chữa và lược bỏ.

Zhixiong Pan：

Chủ đề 1: EOF (Định dạng đối tượng Ethereum)

Định dạng đối tượng Ethereum (EOF) ban đầu được lên kế hoạch triển khai trong bản nâng cấp Thượng Hải, nhưng hiện đã bị trì hoãn. Bản chất của EOF là cung cấp cấu trúc tiền dữ liệu cho mã byte riêng của Ethereum, điều này có lợi cho việc nâng cấp các tính năng mã byte của EVM và hợp đồng thông minh trong tương lai.

Dorothy Liu：

Bản nâng cấp này có tác động nhiều hơn đến toàn bộ hệ sinh thái Lớp 2 hoặc Tổng số không? Đặc biệt, hệ sinh thái Rollup về cơ bản sẽ triển khai một số hợp đồng thông minh trên Lớp 1 của Ethereum, vậy việc nâng cấp này có ảnh hưởng đến các lựa chọn kỹ thuật và đường dẫn liên quan đến Lớp 2 không?

Theo quan điểm của nhóm AltLayer, EOF không phải là một sự đổi mới quá quan trọng. Mặc dù đây là một cải tiến quan trọng đối với mô hình đóng gói của EVM, nhưng nó không có tác động trực tiếp đến việc viết ngôn ngữ Solidity. Do đó, từ góc độ phát triển ứng dụng và phát triển chung, sự thay đổi này ít ảnh hưởng đến họ và thậm chí nhiều nhà phát triển có thể không hiểu vấn đề này và nó sẽ không gây ra vấn đề gì.

Tuy nhiên, đối với Rollup, tác động là rất lớn, vì Rollup thực chất là lớp thực thi của Ethereum. Khi Ethereum thay đổi, Rollup cần điều chỉnh cho phù hợp. Thay đổi EOF này có thể có tác động lớn hơn đến zkEVM, vì zkEVM tương đối khó hơn về mặt kỹ thuật. Chúng là Loại 3 trong phân loại khả năng tương thích của EVM, vì vậy chúng cần phải nỗ lực nhiều hơn để theo đuổi khả năng tương thích cao hơn. Nó thậm chí có thể yêu cầu viết lại hoặc thay đổi rất mạnh mẽ.

Ye Zhang:

Tuy nhiên, đối với những người trong chúng tôi đang thực hiện các dự án Tổng hợp lạc quan, dù được viết bằng WASM hay EVM, chúng tôi đều tương thích với Loại 1, nghĩa là tương thích hoàn toàn với EVM. Do đó, đối với chúng tôi, khó khăn là rất thấp. Mặc dù chúng tôi cần thực hiện một số sửa đổi nhưng độ khó khá thấp. Ngoài ra, các chứng chỉ sản xuất của chúng tôi đều ở WASM, vì vậy đối với chúng tôi, tác động thực tế không lớn.

Đầu tiên, tôi nghĩ EOF thực sự là một bước phát triển công nghệ quan trọng. Trước đây có ý kiến ​​cho rằng zkEVM không cần phải thay đổi thường xuyên vì lõi EVM được nâng cấp ít thường xuyên hơn. Nhưng với EOF gần đây, có thể có những nâng cấp khác sẽ thay đổi logic cốt lõi của EVM, điều này thực sự sẽ có tác động đến zkEVM. Tuy nhiên, hiện tại, do EOF tương thích kỳ hạn nên nó vẫn có khả năng tương thích nhất định với các hợp đồng trước đó. Ít nhất là đối với các hợp đồng và nhà phát triển hiện tại của chúng tôi, tác động trực tiếp là tương đối nhỏ. Có thể có một số điểm cần chú ý trong tương lai, nhưng ít nhất là đối với các hợp đồng Lớp 1 của chúng tôi, tác động sẽ không lớn. Ở Lớp 2, mức độ tác động phụ thuộc vào mức độ chúng tôi hỗ trợ EOF. Chúng tôi chắc chắn bị chậm một chút vì chúng tôi cần hỗ trợ EOF nếu chúng tôi muốn hoàn toàn nhất quán với EVM của Lớp 1.

Trên thực tế, khi chúng tôi phát triển zkEVM, chúng tôi đã chú ý đến việc nâng cấp cốt lõi của EOF, điều này dễ dàng hơn mong đợi. Bởi vì chúng tôi đã áp dụng thiết kế mô-đun khi xây dựng toàn bộ zkEVM, Opcode có thể dễ dàng cập nhật. Đối với EOF, thay đổi chính là thêm một số kiểm soát phiên bản và Opcode, chúng tôi chỉ cần triển khai các Opcode mới này và thực hiện tốt công việc kiểm soát phiên bản, chẳng hạn như thêm một số nhãn và biến trong mạch. Những thay đổi này được thực hiện ở cấp độ Opcode và yêu cầu bổ sung một số mạch. Ngoài ra, EOF cũng thực hiện một số kiểm tra về việc triển khai mã byte, điều này ảnh hưởng đến một mạch con của zkEVM, mạch mã byte. Trong mạch này, chúng ta cần kiểm tra hàm băm đầu vào và xuất mã byte tương ứng. Chúng tôi có thể cần thêm một số ràng buộc vào mạch này nếu chúng tôi cần kiểm tra tại thời điểm này.

Qi Zhou：

Nhìn chung, tôi nghĩ rằng những thay đổi là cần thiết, nhưng không đến mức yêu cầu tái cấu trúc hoàn toàn. Ethereum hiện đã đưa zkEVM lên một vị trí rất quan trọng, và chính họ đang dẫn đầu một số phát triển công nghệ quan trọng. Tôi biết rằng Vitalik và một số thành viên của nhóm cốt lõi EIP cũng quan tâm đến tiến độ của nhóm zkEVM, bao gồm cả việc liên lạc với chúng tôi để hiểu tác động của việc nâng cấp này đối với zkEVM. Bởi vì mỗi lần nâng cấp của Lớp 1 đều mang lại những rủi ro nhất định, trước đây người ta tin rằng mỗi lần nâng cấp có thể không thể đảo ngược. Do đó, chúng tôi hy vọng rằng Lớp 1 càng ổn định càng tốt và lớp dàn xếp càng ổn định thì càng tốt để ít ảnh hưởng đến các ứng dụng và công nghệ hiện có. Ở Lớp 2, chúng tôi có thể thực hiện nhiều đổi mới khác nhau. Tuy nhiên, nếu Lớp 1 cần phải thay đổi, tôi nghĩ Lớp 2 cũng có thể được điều chỉnh cho phù hợp và những thay đổi sẽ không đặc biệt lớn. Nhưng tôi chắc chắn rằng sẽ có một số chậm trễ vì chúng tôi cần triển khai các thay đổi và có thể kiểm tra chúng. Quá trình kiểm tra có thể mất thêm thời gian để hoàn thành, vì vậy chúng tôi thường muốn thực hiện càng ít thay đổi càng tốt. Tuy nhiên, tôi không nghĩ rằng những thay đổi này sẽ có tác động nghiêm trọng đến toàn bộ hệ thống và sẽ không gây ra vấn đề nghiêm trọng.

Về Định dạng đối tượng EVM (EOF), tôi nhận thấy rằng cộng đồng Ethereum cũng đề cập đến nhiều chủ đề liên quan trong các cuộc thảo luận trước đây. Đặc biệt là trong quá trình nâng cấp ở Thượng Hải, chúng ta có thể thấy rằng Ethereum có một số thái độ khác nhau đối với toàn bộ quá trình nâng cấp. Ví dụ, Dankrad, người sáng lập Danksharding, có những nghi ngờ nhất định về EOF. Họ tin rằng mặc dù EOF không thay đổi nhiều đối với các nhà phát triển, nhưng nó chủ yếu cải thiện tính bảo mật của hợp đồng. Về vấn đề này, họ cảm thấy rằng bây giờ không phải là giai đoạn quan trọng nhất của việc mở rộng Ethereum. Trên thực tế, EOF chỉ là một phần rất nhỏ trong kế hoạch mở rộng tổng thể nên đã có rất nhiều tranh cãi về vấn đề này.

Tuy nhiên, tại sao bây giờ bạn lại muốn đưa EOF vào gói nâng cấp của mình? Đó là bởi vì EOF đã được nêu ra trong một thời gian rất dài, có thể là bốn hoặc năm năm, và có thể lâu hơn nữa trong các cuộc thảo luận nội bộ trước đó. Sau khi phân tích EOF, chúng tôi rất đồng ý với một số điểm của Dankrad. Mặc dù EOF mang lại sự bảo mật nhất định cho toàn bộ hợp đồng Ethereum, chẳng hạn như hủy bỏ hoạt động nhảy động tương đối nguy hiểm, nhưng trên thực tế, trong quá trình thực hiện một số lượng lớn các hoạt động thực tế của Ethereum và viết hợp đồng, trình biên dịch đã tạo ra sự cố dễ xảy ra lỗi cơ bản là tránh được. Do đó, chúng tôi chưa gặp phải tình trạng thực thi hợp đồng bất thường do những bước nhảy vọt tương tự trong quá trình phát triển trong những năm gần đây.

Jolestar:

Về việc liệu EOF có bước vào giai đoạn nâng cấp tiếp theo, chẳng hạn như Cancun hay không, xét rằng nó có thể có tác động nhất định đến lớp điện toán Lớp 2 của Ethereum, cá nhân tôi nghĩ rằng có thể có một số tranh cãi. So với EIP-4844 mà chúng ta sẽ thảo luận tiếp theo, vẫn còn nhiều khác biệt về quan điểm đối với EOF.

Về định dạng đối tượng EVM (EOF), nó chủ yếu mang lại hai tối ưu hóa. Đầu tiên, nó tiến hành xác minh mã hợp đồng thông minh và xác minh nó tại thời điểm triển khai. Điều này rất hiệu quả để cải thiện hiệu suất. Hiện tại, nhiều dự án đã áp dụng phương pháp này bằng cách thực hiện xác minh mã trong giai đoạn triển khai. Thứ hai, EOF cung cấp khả năng mở rộng. Mặc dù bản cập nhật này có thể không mang lại những thay đổi lớn, nhưng một khi cơ chế mở rộng này được cung cấp, có thể có nhiều nhu cầu mở rộng trong tương lai. Tại thời điểm này, bạn có thể phải đối mặt với một sự lựa chọn: bạn muốn mở rộng hay tương thích sáng tạo. Đây luôn là một vấn đề nan giải đối với hầu như tất cả các hệ thống phần mềm.

Bằng cách này, EOF thực sự mở ra cơ hội cho những thay đổi trong tương lai. Ví dụ: để triển khai một tính năng Lớp 2 nhất định, một phiên bản mới có thể được thêm vào và một số chức năng mới có thể được thêm vào mã hợp đồng thông minh. Tại thời điểm này, khả năng tương thích với Lớp 1 có thể bị ảnh hưởng. Một sự thay đổi như vậy thực sự có thể gây nhiều tranh cãi. Tuy nhiên, theo quan điểm của tôi, tôi nghĩ rằng đổi mới và phát triển vẫn nên là ưu tiên hàng đầu trong giai đoạn này, chứ chưa phải là đóng băng hoàn toàn. Tất nhiên, đối với Tầng 1, đây là một chiều không gian khác và phán đoán của Tầng 1 và Tầng 2 có thể khác nhau.

Zhixiong Pan：

Chủ đề 2: Trình sắp xếp thứ tự phi tập trung (sequencer)

Hiện tại, Trình tự sắp xếp của hầu hết các mạng Lớp 2 vẫn đang ở giai đoạn đầu và hầu hết trong số chúng là Trình sắp xếp đơn lẻ. Một số dự án có kế hoạch nâng cấp lên Sequencer phi tập trung trong tương lai.

Hiện tại có một thiết kế hợp lý cho một Sequencer phi tập trung không?

Mã thông báo gốc Lớp 2 có thể là một yêu cầu đối với Sequencer phi tập trung không? Chẳng hạn như Optimism/Arbitrum, mặc dù chúng có mã thông báo riêng nhưng chúng chỉ có thể được sử dụng làm mã thông báo quản trị.

Qi Zhou:

Vì vậy, những giải pháp Sequencer tiên tiến hoặc phi tập trung sớm nào khác đáng được chú ý?

Gần đây, chúng tôi đã xem xét một số chủ đề liên quan, chẳng hạn như Arbitrum's Sequencer. Cộng đồng Arbitrum đang đối mặt với một vấn đề lớn là một số lượng lớn các nút (chẳng hạn như 10k kết nối) kết nối với Sequencer để nhận thông tin giao dịch mới nhất và chênh lệch giá từ đó. Nội bộ chúng tôi thường nói đùa rằng liệu Sequencer này có giống với Sàn giao dịch chứng khoán New York hay không, bởi vì có rất nhiều robot định lượng gần Sàn giao dịch chứng khoán New York để nhanh chóng lấy dữ liệu giao dịch qua cáp quang và thực hiện các hoạt động định lượng. Mô hình Sequencer này có khiến chúng ta suy thoái thành một hệ thống rất tập trung không?

Dorothy Liu: 

Tôi nghĩ làm thế nào để nhận ra sự phi tập trung của Sequencer là một vấn đề rất quan trọng. Một số giải pháp tôi có thể nghĩ đến là mượn từ cơ chế Proof of Stake (POS) và sử dụng mã thông báo gốc Lớp 2 làm bằng chứng cổ phần. Bằng cách này, chúng ta có thể đạt được vòng quay trình tự, tương tự như cuộc bầu chọn nhà lãnh đạo an toàn đang diễn ra gần đây của Ethereum. Kết hợp những công nghệ này, tôi nghĩ chúng ta có thể tìm ra một số cách hoàn thiện để giải quyết vấn đề này.

Với câu hỏi này, tôi có thể chia sẻ một số quan sát cá nhân của mình về lịch sử phát triển của Arbitrum và Optimism. Vào đầu năm ngoái, tôi đã đến Amsterdam để tham gia một sự kiện về Rollup do Chainlink tổ chức, lúc đó có bốn đội gồm Arbitrum, Optimism, zkSync và Metis được mời. Trọng tâm của cuộc thảo luận của họ chủ yếu là về mở rộng và hiệu suất. Tôi đã hỏi riêng họ về quan điểm của họ đối với lớp đồng thuận và liệu Rollup có cần thêm lớp đồng thuận hay không. Họ nói rằng họ chỉ đang xem xét việc mở rộng vào lúc này. Chủ nghĩa lạc quan ngay từ đầu đã không tính đến vấn đề này nên giờ không thể thay đổi được.

Theo quan điểm của chúng tôi, chúng tôi đã thiết kế Sequencer phi tập trung ngay từ đầu dự án. Chúng tôi đã thực hiện hai trò chơi Dark Forest và hai chiến dịch NFT Minting, cả hai đều trực tiếp trên mạng chính Ethereum, sử dụng Sequencer phi tập trung. Theo chúng tôi, đây không phải là vấn đề kỹ thuật, mà là di sản của quá trình phát triển lịch sử. Cách họ thay đổi một động cơ trong một hệ thống đang chạy sẽ khó khăn hơn so với việc một dự án mới đã được lên kế hoạch đầy đủ ngay từ đầu.

Về vấn đề mã thông báo, Arbitrum và Optimism đã chứng minh rằng họ có thể hoạt động mà không cần mã thông báo của riêng mình. Nếu bạn muốn có mã thông báo, bạn có thể cần một số thiết kế, chẳng hạn như Chém, v.v. Chúng tôi sẽ phát hành mạng Sequencer phi tập trung vào tháng tới, đây sẽ là mạng Sequencer phi tập trung đầu tiên trên thị trường. Khi đó, chúng ta sẽ có một số thiết kế bao gồm Staking và Slashing.

Ye Zhang:

Cuối cùng, về MEV, mặc dù là hai vấn đề với Sequencer nhưng giữa chúng có mối quan hệ với nhau. Mạng Sequencer phi tập trung có thể giải quyết vấn đề MEV ở một mức độ nhất định. Tuy nhiên, vấn đề này có thể không bao giờ được giải quyết hoàn toàn. Hiện tại, nhóm Arbitrum đã triển khai một số phương pháp, chẳng hạn như thêm các cải tiến về tính ngẫu nhiên, nhưng chúng không thể giải quyết hoàn toàn những vấn đề này. Chúng tôi cũng có thể đề xuất một số giải pháp MEV về phần cứng hoặc cách khác, sẽ được công bố trong tương lai.

Chúng tôi đã thực hiện rất nhiều nghiên cứu về Sequencer và trong khi chúng tôi chưa công bố một giải pháp cụ thể, chúng tôi chắc chắn đang nghiên cứu một thiết kế. Hiện tại có hai hướng chính. Đầu tiên là sơ đồ dựa trên Dung sai lỗi Byzantine (BFT), chẳng hạn như sử dụng Tendermint để chọn một nhà lãnh đạo nhằm thay thế Sequencer tập trung trước đó. Cách tiếp cận này yêu cầu đặt cược và cắt giảm, có thể phát hành mã thông báo riêng cho PoS hoặc kết hợp với các cơ chế đặt lại hoặc tương tự khác. Ưu điểm của BFT là nó có thể cung cấp xác nhận trước rất nhanh và duy trì trải nghiệm người dùng tốt.

Giải pháp thứ hai hứa hẹn hơn là MEV Auction (đấu giá). Chủ nghĩa lạc quan lần đầu tiên đề xuất khái niệm đấu giá MEV, nghĩa là ai đưa ra mức giá cao nhất sẽ có quyền sản xuất các khối. Tuy nhiên, nhược điểm của giải pháp này là người dùng có thể bị robot MEV trả giá quá cao.

Các kế hoạch tương tự bao gồm Cơ sở tổng hợp do Justin Drake đề xuất, ý tưởng cốt lõi của ông là sử dụng lại các trình xác thực Lớp 1 để tạo các khối Lớp 2. Bằng cách này, những người xác thực xây dựng các khối Lớp 1 và Lớp 2 có thể đặt các giao dịch xác minh Lớp 2 vào các khối Lớp 1 khi xây dựng các khối Lớp 1, để giá thầu tổng thể lớn hơn và các khối Lớp 1 được đưa vào trước. Ưu điểm của sơ đồ này là nó rất phù hợp với cơ chế khuyến khích của Lớp 1, nhưng nhược điểm là nó không có xác nhận trước như BFT và trải nghiệm người dùng có thể trở nên kém.

Do đó, các hướng hứa hẹn nhất hiện tại là các kế hoạch dựa trên việc sử dụng lại trình xác thực Lớp 1 và các kế hoạch dựa trên BFT. Chúng tôi đang nỗ lực giải quyết các vấn đề theo các hướng này, chẳng hạn như cung cấp xác nhận trước trong khi sử dụng lại trình xác thực Lớp 1.

Ngoài ra còn có một số hướng cho Sequencer phi tập trung, chẳng hạn như Flashbots và những người khác đã đề xuất một kế hoạch gọi là Trình tự chia sẻ (Shared Sequencer), Superchain của Optimism cũng có thiết kế tương tự. Ý tưởng cốt lõi của việc chia sẻ Sequencer là sử dụng một bộ Sequencer cố định để xử lý các giao dịch trên nhiều chuỗi, hiện thực hóa MEV chuỗi chéo và cải thiện trải nghiệm UI chuỗi chéo. Tuy nhiên, thiết kế này vẫn đang ở giai đoạn đầu và một số vấn đề chính vẫn chưa được giải quyết, chẳng hạn như áp lực nút Sequencer và tính nguyên tử của các giao dịch xuyên chuỗi.

Shared Sequencer có thể có giá trị trong tương lai đối với nhiều tình huống ứng dụng cụ thể (chẳng hạn như các ứng dụng tài sản thời gian thực nhỏ) có thể không có đủ năng lực để chạy một mạng phi tập trung. Tuy nhiên, đối với các ứng dụng nội dung thời gian thực lớn, việc thuyết phục họ sử dụng trình sắp xếp thứ tự được chia sẻ có thể là một thách thức.

Flashbots đang cố gắng triển khai Trình sắp xếp thứ tự được chia sẻ bằng cách xây dựng một mạng phi tập trung về quyền riêng tư để giải quyết vấn đề MEV thiết yếu do thu thập thông tin mang lại và mang lại một mức độ giá trị nhất định cho người dùng. Tuy nhiên, do đề án chưa được công bố đầy đủ nên rất khó đánh giá liệu nó có khắc phục được các tồn tại nêu trên hay không. Là một người chơi MEV có tính chính thống cao, chúng tôi sẽ đánh giá Flashbots một cách chi tiết sau khi nó công khai đề xuất của mình.

Về sự cần thiết của Token, tôi nghĩ nó chủ yếu phụ thuộc vào thuật toán đồng thuận được sử dụng. Nếu thuật toán BFT được áp dụng, thì có thể cần phải có Mã thông báo, nhưng nếu phương pháp dựa trên trình xác thực Lớp 1 hiện có được áp dụng, thì có thể không nhất thiết phải có Mã thông báo, vì tài nguyên của người khác có thể được sử dụng lại. Bằng cách này, nguồn giá trị trở thành người đang đặt cược cho bạn và MEV sẽ chuyển trực tiếp đến trình xác thực mạng. Do đó, cách Lớp 2 xem phần bổ sung giá trị của MEV là yếu tố quyết định.

Tarun Chitra: Ordering So Fair It Ain't Fair Ordering

Về cách xử lý MEV, có lập luận cho rằng trật tự công bằng có thể giải quyết vấn đề MEV ở một mức độ nào đó, nhưng trên thực tế, nó chỉ có thể làm giảm bớt vấn đề MEV. Bởi vì vẫn có thể có nhiều bot khác nhau cạnh tranh để giành quyền ưu tiên, nên tình huống tương tự như tình huống của một công ty thương mại truyền thống. Mặc dù một số tính ngẫu nhiên đã được đưa vào, nhưng điều này vẫn chưa được giải quyết hoàn toàn. Trên thực tế, một nghiên cứu về MEV đã chỉ ra rằng xếp hạng công bằng là không công bằng. Bằng cách xây dựng một mô hình tấn công, các nhà nghiên cứu đã chứng minh rằng trong trường hợp xếp hạng công bằng, trải nghiệm người dùng có thể kém hơn. Do đó, để đạt được sự công bằng thực sự, có thể cần áp dụng các chiến lược sắp xếp khác nhau cho các ứng dụng khác nhau.

Ngoài ra còn có nhiều thí nghiệm thú vị. Ví dụ: giao dịch được mã hóa bằng công nghệ mã hóa (chẳng hạn như VDF) và được giải mã sau khi giao dịch được xác nhận. Theo cách này, không thể dự đoán trước nội dung của giao dịch. Ngoài ra, có các phương pháp như khóa thời gian. Tóm lại, chúng tôi cũng đang chú ý và cải thiện các giải pháp này. Mặc dù chúng ta có một số phương hướng chung, nhưng mỗi phương hướng đều có những vấn đề khác nhau. Do đó, chúng tôi hy vọng sẽ tiến hành phân tích chặt chẽ trước khi hoàn thiện kế hoạch để đảm bảo tính ổn định của kế hoạch. Sequencer liên quan đến nhiều vấn đề như luồng giá trị nên chúng tôi nghĩ chưa có giải pháp hoàn hảo. Đây là lý do tại sao chúng tôi đặt nghiên cứu về Sequencer phía sau.

Hiện tại có một cảm giác chung rằng một Sequencer phi tập trung có thể có lợi cho việc chống kiểm duyệt. Nhưng như tôi đã đề cập trong cuộc thảo luận hôm nay, thực sự bằng phương pháp bắc cầu, có thể đảm bảo rằng các giao dịch được thực thi ở lớp thứ hai. Hơn nữa, hầu hết các thiết kế cầu sẽ quy định rằng nếu bạn không bao gồm một giao dịch, nó có thể bị ảnh hưởng theo một cách nào đó trong một ngày. Tuy nhiên, hầu hết tài chính phi tập trung (DeFi) có thể thanh lý bạn trong phút tiếp theo và sau đó trực tiếp từ chối giao dịch của bạn, điều này có thể mang lại trải nghiệm không tốt cho người dùng. Do đó, chống kiểm duyệt theo thời gian thực là rất quan trọng đối với người dùng và DeFi.

Một vấn đề khác là vấn đề về giá trị có thể trích xuất của công cụ khai thác (MEV). Ví dụ: Arbitrum hiện triển khai chính sách ai đến trước được phục vụ trước, sử dụng trình sắp xếp thứ tự tập trung. Quan điểm trước đây của mọi người là nếu bạn phát hiện ra rằng tôi đang được sử dụng trong MEV, tôi có thể rời khỏi mạng, khiến mọi người không tin vào tính hợp pháp của mạng. Nhưng một vấn đề lớn là khi mạng của bạn bắt đầu và hiệu ứng mạng dần dần xuất hiện, chẳng hạn như một bộ giải trình tự duy nhất, khi hệ sinh thái phát triển đến một quy mô nhất định, khi bạn bắt đầu tính phí hoặc cân nhắc MEV, người dùng thực sự đã trở nên rất phụ thuộc vào bạn. Rất khó để họ chuyển sang các nền tảng khác. Vì vậy, tôi nghĩ rằng mối đe dọa có thể đến trong vài năm tới và họ đột nhiên bắt đầu triển khai MEV, đây là một mối đe dọa tiềm tàng.

Ngoài ra, có những vấn đề tuân thủ. Nếu mã thông báo của bạn được liên kết với Bằng chứng cổ phần (PoS), thì bạn có thể gặp phải một số rủi ro tuân thủ nhất định. Ví dụ: nếu bạn đang tập trung hóa và một quốc gia yêu cầu bạn tắt bộ lập sê-ri hoặc khắc phục một số sự cố nhất định, thì việc phân cấp có thể có một số lợi ích.

Jolestar：

Do đó, chúng tôi đã tiến hành phân tích rất kỹ lưỡng và đầu tư rất nhiều năng lượng theo hướng này. Nếu bất kỳ khán giả nào quan tâm đến nghiên cứu giao thức, vui lòng tham gia cùng chúng tôi. Chúng tôi đang tuyển dụng những tài năng trong lĩnh vực này và chúng tôi sẽ đưa ra những phân tích chi tiết hơn sau.

Về việc giới thiệu BFT làm Sequencer, mọi người đã đạt được sự đồng thuận. Trên thực tế, chúng tôi cần giới thiệu cơ chế đồng thuận BFT ở Lớp 2. Những gì chúng tôi tập trung vào là những gì sự đồng thuận này quyết định. Nếu nó trực tiếp quyết định kết quả, thì chúng ta có thể để nó trực tiếp quyết định. Chúng tôi muốn Lớp 2 cung cấp khả năng mở rộng, vì vậy chúng tôi xem xét Sequencer từ một góc độ khác. Mục đích chính của chúng ta là gì? Một là vì sự an toàn. Trong lược đồ Lớp 2, Sequencer và các lược đồ khác như Proposer hoặc Prover hoặc zk tương tự, chúng có các vai trò khác nhau. Sequencer và Proposer tách biệt trong các tình huống hoạt động và nếu họ muốn gian lận, họ phải cùng nhau gian lận. Ví dụ: Sequencer ẩn các giao dịch và Người đề xuất tạo một gốc giả. An ninh được đảm bảo nếu vai trò của họ được tách ra và đảm nhận bởi các tổ chức khác nhau.

Trước khi Sequencer được gửi đến Lớp 1, thứ tự của các giao dịch có thể được điều chỉnh bởi Sequencer và có thể có chỗ cho gian lận. Để loại bỏ vấn đề này, chúng tôi để Sequencer cung cấp bằng chứng tương tự như bằng chứng gian lận, được gọi là Chứng minh trình tự. Bạn biện minh cho việc đặt giao dịch ở một vị trí, đưa ra một cam kết. Nếu thứ tự của liên kết cuối cùng không phù hợp với cam kết, Sequencer có thể bị thách thức và trừng phạt.

Cuối cùng, nếu chúng tôi thực sự muốn giới thiệu bỏ phiếu BFT, chúng tôi nên quyết định thứ tự giao dịch chứ không phải kết quả của giao dịch. Cơ chế đồng thuận hiện tại xác định phiếu bầu kết quả thực hiện cuối cùng và không xác định thứ tự giao dịch của chuỗi khối. Do đó, trong trường hợp này, chúng tôi có thể cần đưa ra một sự đồng thuận nhạy cảm với trật tự hoặc tính công bằng, cho phép mọi người bỏ phiếu theo thứ tự giao dịch. Đây là một hướng mà chúng tôi hiện đang khám phá và là một giải pháp để phân quyền với Sequencer.

Zhixiong Pan：

Chủ đề 3: EIP-4844 (Proto-Danksharding)

Ngoài EOF, một triển khai quan trọng khác của việc nâng cấp và mở rộng lớp giao thức là EIP-4844, đặc biệt liên quan chặt chẽ đến nhóm Lớp 2. Vào đầu năm, Lễ kỷ niệm của KZG đã được ra mắt và việc bổ sung lớp giao thức có thể mất một thời gian. Đối với hướng Rollup, ZK Rollup hoặc mở rộng, bạn nghĩ nhóm Lớp 2 có thể mất bao lâu để tích hợp EIP-4844?

Jolestar：

Về việc tích hợp EIP-4844, bạn nghĩ có thể gặp phải những khó khăn gì? Ngoài ra, bạn đã ước tính tác động của việc sử dụng EIP-4844 đối với GAS hoặc mở rộng tổng thể chưa?

Theo hiểu biết của tôi, việc tích hợp EIP-4844 không thay đổi nhiều so với sơ đồ Tổng số ban đầu. Chúng tôi đã tìm kiếm một giải pháp có TPS cao hơn và phí thấp hơn, nhưng chỉ dựa vào EIP-4844 thì không thể giải quyết vấn đề này. Trên thực tế, nó chỉ thêm một loại giao dịch, loại Blob, trong khi giới hạn kích thước khối tổng thể vẫn bị giới hạn bởi lớp cơ sở. Nếu chúng ta muốn đạt được Lớp 2 lý tưởng với TPS hàng trăm nghìn hoặc gần 100.000, thì các giao dịch của lớp đầu tiên vẫn không thể được đặt trực tiếp vào một khối.

Dorothy Liu：

Do đó, mục tiêu của chúng tôi bây giờ là triển khai một phương thức trong đó các giao thức khác nhau có thể kết hợp được, để lựa chọn giữa các giao thức ít tốn kém hơn, dễ sử dụng và có thông lượng lớn hơn.

Đầu tiên, việc nâng cấp EIP-4844 tương đối dễ dàng đối với OP của chúng tôi để tích hợp, trong khi zkEVM có thể khó khăn hơn. Zhang Ye có thể cung cấp cho bạn những câu trả lời chuyên nghiệp về bản nâng cấp này. Ngoài ra, tôi muốn chia sẻ một giao thức có tên Monad mà người sáng lập tên là Keone và bạn có thể theo dõi anh ấy trên Twitter. Keone, nhà phát triển của Jump, là một thiên tài toán học với sở trường tính toán. Anh ấy đã đăng trên Twitter dự đoán của mình về việc ra mắt giao thức EIP-4844, dự đoán rằng TPS của Arbitrum có thể tăng lên khoảng 160, nhưng con số này có đáng kể hay không là tùy thuộc vào người xem. Việc có thể cải thiện phương pháp tính toán của anh ấy hay không vẫn còn gây tranh cãi, nhưng chúng tôi tin rằng EIP-4844 chỉ có thể cải thiện hiệu suất ở một mức độ nhất định và cuối cùng vẫn phụ thuộc vào sự kết hợp giữa EIP-4844 và Rollup và có thể yêu cầu nhiều Rollup để cải thiện hiệu suất. Bản thân EIP-4844 không giải quyết được gì nhiều.

Ye Zhang:

Đối với chúng tôi, dịch vụ mà chúng tôi cung cấp được gọi là "Rollup as a Service", như Zhang Ye đã đề cập, nhiều ứng dụng (chẳng hạn như trò chơi và giao thức DeFi) yêu cầu thông lượng cao và khi yêu cầu về thành phần không cao, chúng có thể chạy trên một Tổng số. Các Rollup này sẽ chia sẻ một mạng Sequencer phi tập trung và các mạng Prover và Validator cũng sẽ được phân cấp. Đây là một giả định về việc cung cấp dịch vụ hiện tại của chúng tôi và chúng tôi sẽ cung cấp thêm thông tin chi tiết trong tháng tới. Do đó, chúng tôi tin rằng EIP-4844 hiện có hoặc một giải pháp Tổng số duy nhất không thể giải quyết tất cả các vấn đề và điều quan trọng là dựa vào một số lượng lớn các Tổng số để cung cấp dịch vụ cho các dự án và kịch bản ứng dụng khác nhau.

Về EIP-4844, chúng tôi đang nghiên cứu nó. EIP-4844 chắc chắn sẽ giảm một số chi phí dữ liệu. Gần đây, có một cuộc thảo luận trên Twitter về chi phí dữ liệu của Polygon và zkSync. Cả chúng tôi và Polygon hiện đang sử dụng dữ liệu thô của các giao dịch trực tiếp trên chuỗi. Optimism và Arbitrum sẽ được nén ở một mức độ nhất định trước khi được tải lên chuỗi, trong khi zkSync và StarkWare sẽ sử dụng chế độ State Diff tiết kiệm không gian hơn. Đối với các hoạt động tần suất cao trên cùng một tài khoản, State Diff có thể tiết kiệm rất nhiều dung lượng. Ai đó đã phân tích dữ liệu của zkSync sau khi sử dụng State Diff và nhận thấy rằng nó thực sự có thể tiết kiệm một khoản chi phí nhất định. Tuy nhiên, nếu chi phí dữ liệu giảm hơn nữa sau EIP-4844 hoặc sharding, chúng tôi vẫn muốn tải trực tiếp dữ liệu gốc của giao dịch chuỗi lên, vì điều này sẽ cho phép những người khác thực hiện giao dịch nhanh hơn sau khi xem dữ liệu của bạn và có được sự đảm bảo mạnh mẽ hơn.

Chúng tôi hy vọng rằng sau khi chi phí dữ liệu trở nên thấp hơn, việc thêm một số thuật toán nén có thể đạt được hiệu quả tương tự như của State Diff. Nhưng hiện tại chúng tôi thích sử dụng dữ liệu thô của giao dịch hơn. Đối với tác động của EIP-4844 đối với chúng tôi, nó sẽ ảnh hưởng đến hai phần: một là cầu của chúng tôi (Cầu), chúng tôi đã bắt đầu khám phá thiết kế cầu mới theo EIP-4844, sẽ có một số tác động và một thông số kỹ thuật mới cần được viết . Phần nữa là ở mạch của chúng ta (Circuit), do ở dạng mới không truy cập trực tiếp được dữ liệu trước đó mà chỉ có một cam kết nhỏ (Commitment) nên chúng ta cần chứng minh tính mở của cam kết này trong mạch. Chắc chắn có một chi phí cho mạch, nhưng chúng tôi nghĩ rằng nó có thể thực hiện được.

Qi Zhou：

Việc triển khai EIP-4844 sẽ liên quan đến sự cố miền vì dữ liệu nằm trên một đường cong khác, có thể không có cùng định dạng với dữ liệu gốc. Cách đây rất lâu, Vitalik đã đề xuất khái niệm chứng minh sự tương đương, nhưng sau đó phát hiện ra rằng nếu các miền khác nhau thì vẫn còn một số vấn đề. Dankrad và Vitalik đề xuất một cách tinh vi để kết hợp tính cởi mở đã cam kết vào các mạch. Chúng tôi cho rằng sự thay đổi này là dứt khoát và cần có thời gian, nhưng nó không đặc biệt phức tạp và khả thi. Chúng tôi cần phối hợp khi Lớp 1 thực hiện thay đổi này và sau đó chúng tôi điều chỉnh cho phù hợp. Cho đến lúc đó, chúng tôi sẽ tiếp tục tập trung vào hệ thống hiện tại.

Chúng tôi đã nghiên cứu rất nhiều về EIP-4844. Trên thực tế, mục đích của EIP-4844 không phải là mở rộng dung lượng, mà là hiện thực hóa một tập hợp các khái niệm cần thiết cho Danksharding trong tương lai, bao gồm Đối tượng lớn nhị phân (blob) và Băm dữ liệu của nó. Data Hash có thể được truy cập trong hợp đồng và các khái niệm này được triển khai trước để không cần nâng cấp hợp đồng khi triển khai Danksharding. EIP-4844 sẽ không mang lại những cải tiến đáng kể so với phương pháp dữ liệu trên chuỗi Ethereum hiện tại.Chúng tôi đã ước tính sơ bộ rằng băng thông mà chúng mang lại về cơ bản có cùng mức độ lớn.

Tuy nhiên, theo thông số kỹ thuật của Danksharding, mức thông lượng cao hơn khoảng 20 lần. Do đó, giả sử chúng ta đạt được tốc độ 100 TPS trên EIP-4844, thì việc sử dụng Danksharding về mặt lý thuyết có thể đạt tới 2000 TPS, hoặc thậm chí cao hơn. Cộng đồng Ethereum, bao gồm Vitalik Buterin và nhóm Danksharding, rất quan tâm đến bản nâng cấp EIP-4844, bởi vì một khi nó được nâng cấp, bản nâng cấp lớn tiếp theo của Ethereum sẽ không cần nâng cấp toàn bộ hệ thống hợp đồng.

Hợp đồng lưu trữ của chúng tôi được thiết kế trực tiếp cho EIP-4844, điều này thực sự có thể đơn giản hơn về triển khai phát triển và bằng chứng lưu trữ. Sử dụng Danksharding do EIP-4844 cung cấp, hệ thống thực sự đã được tính toán trước, đây là một phương pháp lưu trữ rất thân thiện với chúng tôi.

Có thể có những thách thức với các công nghệ như ZK và Optimism, đặc biệt là về cách truyền dữ liệu. Ethereum đã có một số công cụ, bao gồm các phương pháp đánh giá ngẫu nhiên, có thể truyền lại dữ liệu blob vào CoreData. Chúng tôi cần một số thách thức để chứng minh rằng các giao dịch này là chính xác.

Chúng tôi dự định cung cấp một số thư viện chung, tương tự như thư viện OpenZeppelin, để hỗ trợ các thao tác khác nhau trên các đốm màu dữ liệu trên EIP-4844. Điều này sẽ mang lại lợi thế về an ninh và hiệu quả về kiểm toán và tiêu thụ gas.

Tóm lại, EIP-4844 mang tính sáng tạo và có tiềm năng lớn cho hoạt động của toàn bộ lớp dữ liệu của Ethereum. Đối với những người quan tâm đến EIP-4844, nên nghiên cứu thiết kế tham số và mã liên quan đến Ethereum để hiểu rõ hơn về cách sử dụng công nghệ này.

Zhixiong Pan：

Chủ đề 4: Chuỗi khối mô-đun

Jolestar:

Chủ đề cuối cùng là cùng các bạn thảo luận về blockchain mô-đun, đây là một chủ đề nóng liên quan chặt chẽ đến bản thân chuỗi công khai và có thể nói là một xu hướng mới. Mặc dù đã hơn một năm kể từ đầu năm ngoái, nhưng hiện tại có một quan điểm lớn là blockchain có thể dần dần được phân lớp, hình thành các cấp độ khác nhau như đồng thuận, thực thi, DA hoặc thanh toán. Trong bối cảnh như vậy, liệu các giao thức Lớp 2 có phải đối mặt với những thách thức và cạnh tranh lớn hơn hay không và liệu bối cảnh cạnh tranh của toàn ngành có trải qua những thay đổi lớn hay không.

Tôi nghĩ rằng chuỗi khối mô-đun là một sự phát triển của ý tưởng Lớp 2. Vì ở Lớp 2, chúng tôi đã chuyển việc thực thi từ Lớp 1 sang Lớp 2, tại sao chúng ta không thể phân tách các mô-đun khác nhau và để các hệ thống khác nhau đảm nhận chúng. Điều này đưa ra một quan điểm khác, đó là lấy hệ thống phân tán truyền thống làm ví dụ.Trong hệ thống phân tán truyền thống, chúng ta có một lớp đồng thuận gọi là Zookeeper và Raft. Lớp đồng thuận như vậy tương đương với Lớp 1 trên chuỗi khối. Tuy nhiên, Lớp 1 của chuỗi khối khác với lớp đồng thuận truyền thống, Lớp 1 của chuỗi khối có thể chạy các chương trình. Vì vậy, bây giờ chúng tôi chạy chương trình trong Zookeeper, nhưng thấy rằng hiệu quả thực thi của sự đồng thuận toàn cầu quá chậm, chúng tôi cần loại bỏ nó để mở rộng.

Một quan điểm khác là từ quan điểm ứng dụng, khi chúng tôi xây dựng ứng dụng, chúng tôi chọn các thành phần hệ thống khác nhau để hoàn thành các chức năng của ứng dụng, chẳng hạn như Zookeeper hoặc MySQL. Trên thực tế, chúng tôi đang xây dựng các ứng dụng, không phải MySQL đang mở rộng Zookeeper. Ý tưởng chuỗi khối mô-đun này có thể giới thiệu một viễn cảnh mới, đó là cách chúng ta có thể sử dụng các tài nguyên Lớp 1 hiện có, cũng như các chức năng lưu trữ và thực thi, để kết hợp nhằm xây dựng một DApp cơ bản.

Dorothy Liu:

Quan điểm mới này không xung đột với các chuỗi công cộng hiện có và các thành phần của hệ thống chế tạo. Chúng tôi tin rằng các nhà phát triển trước tiên cần chọn một ngôn ngữ phù hợp để xây dựng các ứng dụng để đảm bảo tính xác định và khả năng kiểm chứng. Chúng tôi đã chọn ngôn ngữ Move để có khả năng mở rộng tốt hơn. Các nhà phát triển sử dụng ngôn ngữ này để xây dựng các ứng dụng, sau đó nghĩ về cách đạt được sự phân cấp. Nó có thể không được phân cấp hoàn toàn ngay từ đầu, nhưng khả năng phân cấp là bắt buộc. Ví dụ: các giao dịch có thể được công khai để bất kỳ ai cũng có thể xác minh chúng. Trong khi vẫn tập trung, ít nhất là có thể kiểm chứng được. Sau đó, một giao thức có thể được cắm vào để đảm bảo an ninh, như một lời hứa. Cơ chế hoàn thiện dần dần này cung cấp một lộ trình phát triển mới cho các ứng dụng tập trung.

Tôi rất đồng ý với quan điểm của Jolestar.Kể từ năm ngoái, chúng tôi đã nhận ra rằng ngành đã phát triển từ các giao thức béo và các ứng dụng mỏng sang các ứng dụng béo và các giao thức mỏng. Giờ đây, trọng tâm chuyển từ việc theo đuổi tiến bộ công nghệ và điều không tưởng phi tập trung sang các kịch bản ứng dụng thực tế. Với sự xuất hiện của ngày càng nhiều ứng dụng mới như trò chơi và mạng xã hội, mọi người chú ý nhiều hơn đến những gì ứng dụng blockchain có thể đạt được, thay vì chỉ mở rộng Ethereum hoặc phát triển một hướng kỹ thuật nhất định. Mặc dù Ethereum là một L1 quan trọng, nhưng với sự xuất hiện của các L1 khác nhau, mọi người đều sẵn sàng chấp nhận đánh đổi trong kỷ nguyên đa chuỗi.

Là một công ty hoặc nhóm định hướng Rollup, chúng tôi không chỉ phục vụ cộng đồng Ethereum. Chúng tôi hy vọng sẽ xây dựng một giải pháp công nghệ Lego tháo rời và kết hợp để đáp ứng nhu cầu của các ứng dụng khác nhau. Một số ứng dụng có thể yêu cầu giới hạn khối lớn hơn, một số công ty trò chơi có thể muốn L2 tương thích với Solana VM, ai đó có thể muốn đưa DA lên Celestia hoặc tương thích với EigenLayer. Chúng tôi muốn cung cấp một giải pháp có thể kết hợp và tùy chỉnh các giải pháp cho các ứng dụng khác nhau theo nhu cầu của họ. Chúng tôi có thể đặt L1 trên Chuỗi Ethereum, BNB hoặc thậm chí Solana hoặc Lớp Beacon của riêng chúng tôi. Từ quan điểm bảo mật, việc đưa bằng chứng lên Ethereum là rất quan trọng, nhưng cơ quan giao dịch (bản thể luận giao dịch) không nhất thiết phải đặt trên Ethereum. Khởi hành từ cơ quan giao dịch của Ethereum sẽ giảm đáng kể chi phí.

Qi Zhou:

Trong kỷ nguyên ứng dụng béo bở này, chúng tôi tập trung vào cách cung cấp giải pháp mở rộng phù hợp nhất cho từng ứng dụng, chứ không chỉ hướng tối ưu hóa. Đối với tranh luận giữa zkEVM và OP, chúng tôi có thể hỗ trợ cả hai bên. Chúng tôi tập trung vào chi phí chứng minh của zkEVM. Ví dụ: Scroll có thể cần chi 10.000 đô la một tháng để chạy một chứng minh, điều này có thể quá đắt đối với các nhà sản xuất trò chơi. Họ cần một giải pháp chứng minh rẻ hơn.Chúng tôi có thể cung cấp giải pháp chứng minh bằng máy tính và cung cấp các giải pháp kỹ thuật khác nhau tùy theo các nhu cầu khác nhau. Đây là giải pháp của chúng tôi.

Từ góc độ lịch sử, tôi đồng ý với hướng đi của tính mô đun. Điều này bao gồm các lớp OSI trong mạng cũng như kiến ​​trúc máy tính. Coi Ethereum hay blockchain là máy tính thế giới, chúng ta có thể học hỏi từ hệ thống máy tính hiện có để phát huy tốt hơn vai trò của nó. Vì mỗi thành phần có giá trị thị trường rất lớn, ví dụ, Lớp 1 của Ethereum có thể được so sánh với một CPU đời đầu với sức mạnh tính toán cơ bản và dung lượng lưu trữ hạn chế. DA, mặt khác, giống bộ nhớ hơn.

Giữa bộ nhớ và CPU, chúng ta cần băm dữ liệu và tiền biên dịch để truyền dữ liệu. Coredata tương tự như các thanh ghi và chúng ta cũng cần các plug-in mô-đun, chẳng hạn như các thiết bị điện toán hiệu suất cao như GPU. Trong mạng chuỗi khối, việc truyền dữ liệu tính toán được thực hiện thông qua DA và bằng chứng không kiến ​​thức. Ngoài ra, chúng ta cần nhiều dung lượng lưu trữ để sao chép dữ liệu từ bộ nhớ sang đĩa cứng. Cuối cùng, chúng tôi cũng cần các thiết bị như chuột, bàn phím và màn hình, tương tự như giao thức MetaMask và Web3 mà chúng tôi sử dụng hiện nay.

Rút ra bài học từ những hệ thống máy tính trưởng thành và đúc rút kinh nghiệm, chúng ta có thể hình dung ra hệ thống thế giới máy tính trong tương lai. Tất nhiên, chúng ta cũng có thể kết nối đĩa cứng với các máy tính khác, chẳng hạn như các thiết bị Lớp 1 khác. Tuy nhiên, nếu Lớp 1 không có lớp DA và bộ nhớ tốt, tốc độ và băng thông truyền và lưu trữ dữ liệu sẽ bị hạn chế rất nhiều.

Ye Zhang：

Máy tính không thể khởi động nếu không có CPU và bộ nhớ, đây là một phần rất quan trọng. Với các thành phần cơ bản này, chúng ta có thể kết hợp các thiết bị như GPU, màn hình và ổ cứng. Khi phát triển các giao thức EthStorage và Web3, chúng tôi đã hỗ trợ nhiều chuỗi và áp dụng phương pháp mô-đun để truy cập các mạng khác. Các mạng này có thể là Lớp 1 hoặc Lớp 2 khác miễn là chúng có các lớp DA và thực thi cơ bản. Khi truy cập Lớp 2, EthStorage thực sự trở thành Lớp 3 ở một mức độ nào đó. Đây là tầm nhìn của chúng tôi về kiến ​​trúc tổng thể của các máy tính hoặc chuỗi khối trên thế giới trong tương lai.

Tôi nghĩ rằng các chuỗi khối mô-đun thực sự là một câu chuyện rất quan trọng ngay bây giờ, sự tách biệt giữa thực thi và dữ liệu. Tuy nhiên, ít nhất là đối với chúng tôi, hiện tại chúng tôi vẫn coi Ethereum là lớp dữ liệu quan trọng nhất. Về định nghĩa Rollup, có nhiều cách giải thích khác nhau vì nhiều Rollup khác nhau đang xuất hiện. Hiện tại, một định nghĩa được hầu hết cộng đồng chấp nhận là ít nhất bạn cần xuất bản dữ liệu lên Lớp 1, ngay cả khi bạn không xuất bản bằng chứng, bạn vẫn cần xuất bản dữ liệu lên Ethereum, để kế thừa tính bảo mật của Ethereum. Bởi vì hầu hết mọi người nghĩ rằng miễn là dữ liệu được tải lên chuỗi, cho dù thông qua các nút khác, nút đầy đủ hay nút nhẹ, thì ít nhất có thể thu được một kết quả xác định và nó phải được hoàn thiện.

Về các Rollup khác nhau, ý tưởng chính của họ là việc bạn có tin vào kết quả hay không tùy thuộc vào lựa chọn của chính bạn, nút đầy đủ hay nút nhẹ mà bạn chọn. Ví dụ: Tổng hợp lạc quan sẽ nói "Tôi thách thức bạn", trong khi zkRollup sẽ nói "Tôi luôn chứng minh bạn đúng". Trên thực tế, tất cả các Tổng số này chỉ nhằm mục đích thiết lập một điểm, để quyết định xem tôi có tin tưởng dữ liệu của bạn hay không và liệu tôi có tin tưởng tiền của bạn sẽ được bắc cầu từ bạn hay không.

Do đó, ít nhất là đối với chúng tôi, chúng tôi hy vọng rằng nền tảng của chúng tôi sẽ luôn tin tưởng vào lớp dữ liệu của Ethereum và kiên quyết thực hiện Rollup. Chúng tôi cũng sẽ làm việc chăm chỉ để thúc đẩy quá trình Chia sẻ dữ liệu. Tôi nghĩ điều duy nhất cần tập trung vào là thời gian, chính xác thì nó sẽ xảy ra khi nào và mất bao lâu. Cho đến lúc đó, chúng ta có cần thực hiện các biện pháp chuyển tiếp không? Điều này chủ yếu phụ thuộc vào ước tính của chúng tôi về dòng thời gian bảo vệ dữ liệu. Nếu chúng tôi ước tính rằng sẽ mất 5 năm để đạt được, thì chúng tôi có thể có một số bước trung gian. Nhưng nếu chúng tôi nghĩ rằng nó sẽ xảy ra trong một khung thời gian hợp lý, chúng tôi sẽ vẫn đi theo hướng này.

Mô-đun quá mức có thể không phải là một điều tốt. Khi chúng tôi quan sát tình hình của Lớp 2 trước đây, có thể chỉ có chín Lớp 2, mỗi lớp có các thuộc tính bảo mật riêng, chẳng hạn như liệu hợp đồng có thể được nâng cấp hay không, Sequencer có được phân cấp hay không, liệu nó có phải là nguồn mở hay không. nó đã được kiểm toán. Đối với Lớp 2, các thuộc tính bảo mật này rất phức tạp. Ví dụ: nếu hợp đồng có thể được nâng cấp, nếu Bản tổng hợp không tuân thủ thực hiện điều gì đó không tốt, nó có thể bị phát hiện ngay lập tức. Nếu công chúng nói chung không hiểu các thuộc tính của các Bản tổng hợp khác nhau và sự đánh đổi giữa chúng và đã có 100 Bản tổng hợp để lựa chọn, một số vấn đề bảo mật có thể phát sinh. Do đó, tôi nghĩ rằng cuối cùng vẫn có thể có một số Rollup chính cung cấp bảo mật tuyệt đối và mọi người đều có những đảm bảo nhất định cho tài sản của mình, đồng thời có khả năng kết hợp tốt. Trên cơ sở này, có thể giảm bớt áp lực cho Lớp 2, cho dù đó là phát triển song song Lớp 2 của một số lớp ứng dụng hay triển khai Lớp 3 trên nó.

Tại thời điểm này, họ có thể chọn sử dụng các lớp dữ liệu khác hoặc các phương pháp khác, miễn là cộng đồng đạt được sự đồng thuận, họ có thể đổi mới theo ý tưởng của mình.