Bốn nhóm mở rộng nói về các công nghệ tiên tiến của Ethereum: Trình tuần tự phi tập trung, EOF, 4844 và tính mô đun

Tiêu đề gốc: " Bốn nhóm mở rộng nói về các công nghệ tiên tiến của Ethereum: Trình tuần tự phi tập trung, EOF, 4844 và tính mô đun 》

Tác giả gốc: Zhixiong Pan

Trong sự kiện "Hội nghị thượng đỉnh 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 tham dự. Hãy nói về việc cắt- công nghệ tiên tiến của Ethereum.

Cụ thể là EOF và EIP-4844 có thể được đưa vào bản nâng cấp tiếp theo (Cancun). Ngoài ra, câu chuyện về Sequencer phi tập trung và blockchain mô-đun cũng là một hướng đi mới được các nhà nghiên cứu chú ý hơn.

Bốn nhóm này có những đặc điểm riêng biệt, chẳng hạn như tập trung vào lĩnh vực chứng minh không có kiến thức (đặc biệt là zkEVM), tập trung vào WASM và mở rộng năng động, và tập trung vào ngôn ngữ và mô-đun Move, 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.

Những người tham gia cuộc thảo luận này là:

Dorothy Liu từ AltLayer

Jolestar từ Rooch Network

Qi Zhou từ EthStorage

Ye Zhang từ Cuộn

TLDR

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 Trình sắp xếp chuỗi phi tập trung: Dung sai lỗi Byzantine (BFT), đấu giá MEV, Bộ sắp xếp chuỗi chia sẻ (Flashbots), VDF, v.v. Ngoài ra, việc phân loại công bằng có thể không công bằng, đòi hỏi các chiến lược ứng dụng khác nhau.

Mục đích của EIP-4844 không phải là mở rộng công suất mà là để triển khai 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 Blobs và Data Hash của chúng. Triển khai trước các khái niệm này để không cần nâng cấp hợp đồng khi triển khai Danksharding. EIP-4844 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 và băng thông mà chúng mang lại về cơ bản có cùng độ lớn.

Mọi người đều có những quan điểm hoàn toàn khác nhau về blockchain mô-đun: một số người nghĩ rằng trong thời đại của các ứng dụng béo bở, cần phải cung cấp nhiều lựa chọn đa dạng hơn; một số người nghĩ rằng chúng tôi nên học hỏi từ hệ thống máy tính trưởng thành, nhưng một số người tin rằng nó không nên quá mô-đun và Ethereum là lớp dữ liệu quan trọng nhất.

Sau đây là toàn văn cuộc thảo luận, được OpenAI Whisper dịch và GPT-4 xử lý. Một số điều chỉnh và việc xóa đã được thực hiện.

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

Zhixiong Pan:

Định dạng đối tượng Ethereum (EOF) ban đầu được lên kế hoạch nâng cấp ở Thượng Hải Thực hiện vào năm 2016 nhưng hiện đã bị trì hoãn. Bản chất của EOF là cung cấp cấu trúc dữ liệu mặt trước cho mã byte tự 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 và hợp đồng thông minh của EVM trong tương lai.

Liệu 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 Rollup 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 lên Ethereum Lớp 1. Vậy việc nâng cấp này có ảnh hưởng đến các lựa chọn công nghệ và lộ trình liên quan đến Lớp 2 không?

Dorothy Liu:

Theo ý kiến 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 bằng ngôn ngữ Solidity. Vì vậy, từ góc độ phát triển ứng dụng và phát triển chung, sự thay đổi này sẽ ít ảnh hưởng đến họ, 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 về cơ bản là lớp thực thi của Ethereum. Khi Ethereum thay đổi, Rollup cần phải đ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ó khăn hơn về mặt kỹ thuật. Chúng thuộc Loại 3 trong phân loại khả năng tương thích EVM, vì vậy chúng đòi hỏ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ẽ.

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

Ye Zhang:

Trước hết, 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ó quan điểm cho rằng zkEVM không cần thay đổi thường xuyên vì có ít bản nâng cấp lõi EVM hơn. Nhưng với EOF gần đây, có thể có những nâng cấp khác làm 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 có tính 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 đố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 sẽ rất nhỏ. Có thể có một số điều cần chú ý sau này, nhưng ít nhất đối với hợp đồng Lớp 1 của chúng ta, tác động sẽ không lớn. Ở Lớp 2, 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 sẽ bị chậm một chút vì nếu muốn hoàn toàn nhất quán với EVM của Lớp 1, chúng tôi cần hỗ trợ EOF.

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, việc này dễ dàng hơn mong đợi. Vì chúng tôi đã áp dụng thiết kế mô-đun khi xây dựng toàn bộ zkEVM nên Opcode có thể được cập nhật dễ dàng. Đối với EOF, thay đổi chính là thêm một số điều khiển phiên bản và Opcode, chúng ta chỉ cần triển khai các Opcode mới này và thực hiện công việc tương ứng trong điều khiển phiên bản, chẳng hạn như thêm một số nhãn và biến vào mạch. Những thay đổi được thực hiện ở cấp độ Opcode và yêu cầu bổ sung một số mạch điện. 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ạ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à đầu ra mã byte tương ứng. Nếu cần kiểm tra liên kết này, chúng ta có thể cần thêm một số ràng buộc vào mạch.

Nhìn chung, tôi nghĩ những thay đổi này là cần thiết, nhưng chưa đến mức phải tái cấu trúc hoàn toàn. Ethereum hiện đã nâng zkEVM lên một vị trí rất quan trọng và bản thân họ đang dẫn đầu một số phát triển kỹ thuật 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 lo ngại về tiến độ của nhóm zkEVM, bao gồm cả việc liên hệ 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 Lớp 1 sẽ mang đến những rủi ro nhất định nên trước đây một số người tin rằng mỗi lần nâng cấp có thể không thể đảo ngược được. Vì vậy, chúng tôi muốn Lớp 1 càng ổn định càng tốt, lớp lún càng ổn định thì càng tốt, nhờ đó tác động đến các ứng dụng và công nghệ hiện có sẽ nhỏ hơn. Ở Lớp 2, chúng tôi có thể thực hiện tất cả các loại đổi mới. Tuy nhiên, nếu Lớp 1 cần 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 đáng kể. Nhưng tôi chắc chắn sẽ có một số chậm trễ vì chúng tôi cần thực hiện các thay đổi và có thể thực hiện kiểm tra. 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 những thay đổi ở mức tối thiểu nhất có thể. Tuy nhiên, tôi nghĩ những thay đổi này sẽ không 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.

Tề Châu:

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 đó. Đặc biệt trong quá trình nâng cấp Thượng Hải, chúng ta có thể thấy 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 đối với sự mở rộng của Ethereum. Trên thực tế, EOF chỉ là một phần rất nhỏ trong toàn bộ kế hoạch mở rộng nên có rất nhiều tranh cãi về vấn đề này.

Tuy nhiên, tại sao bạn lại muốn đưa EOF vào kế hoạch nâng cấp của mình ngay bây giờ? Đó là bởi vì EOF đã được đề xuất từ rất lâu, có thể là 4 hoặc 5 năm trước, và có thể lâu hơn 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 đồng ý với một số quan điểm của Dankrad. Mặc dù EOF mang lại một mức độ 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 một số lượng lớn các hoạt động thực tế và quy trình viết hợp đồng của Ethereum, trình biên dịch đã làm cho lớp dưới cùng dễ dàng bị tấn công. phạm sai lầm Vấn đề được tránh. Vì vậy, chúng tôi chưa gặp phải trường hợp thực hiện hợp đồng bất thường nào 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.

Về việc liệu EOF có bước vào giai đoạn nâng cấp tiếp theo hay không, chẳng hạn như Cancun, vì 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ĩ vậy là có thể Vẫn còn một số tranh cãi. So với EIP-4844 mà chúng ta sẽ thảo luận tiếp theo, các ý kiến về EOF vẫn còn chia rẽ hơn.

Jolestar:

Về Định dạng đối tượng EVM (EOF), nó chủ yếu mang lại hai cách tối ưu hóa. Đầu tiên, nó chuyển tiếp xác minh mã hợp đồng thông minh và xác minh nó trong quá trình 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 tiến hành 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ể sẽ 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 sự lựa chọn: tiện ích mở rộng sáng tạo hoặc khả năng tương thích. Đây thực sự là một vấn đề nan giải mà tất cả các hệ thống phần mềm phải đối mặt.

Bằng cách này, EOF thực sự mở ra cánh cửa 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, bạn có thể thêm phiên bản mới và thêm một số chức năng mới 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. Sự thay đổi nà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 tin rằng sự đổi mới và tiến hóa vẫn phải là ưu tiên hàng đầu trong giai đoạn này và nó vẫn chưa phải là sự đóng băng hoàn toàn. Tất nhiên, đối với Lớp 1, đây là một không gian khác và các nhận định của Lớp 1 và Lớp 2 có thể khác nhau.

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

Zhixiong Pan:

Hiện tại, hầu hết các Trình sắp xếp mạng lớp 2 vẫn còn ở giai đoạn đầu, hầu hết đều là đơn lẻ trình tự sắp xếp. 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ó thiết kế Sequencer phi tập trung hợp lý không?

Có thể nào Mã thông báo gốc của Lớp 2 trở thành điều kiện cần thiết để hiện thực hóa Trình sắp xếp chuỗi phi tập trung? Chẳng hạn như Chủ nghĩa lạc quan/Trọng tài, mặc dù nó có cái riêng của nó. Mã thông báo , nhưng chỉ có thể được sử dụng như một công cụ quản lý Mã thông báo . Vì vậy, những giải pháp Sequencer phi tập trung sớm hoặc tiên tiến nào khác đáng được chú ý?

Tề Châu:

Gần đây chúng tôi đã xem xét một số chủ đề liên quan, chẳng hạn như Trình sắp xếp thứ tự của Arbitrum. Cộng đồng Arbitrum phải đối mặt với một vấn đề lớn, đó là một số lượng lớn các nút (như 10.000 kết nối) kết nối với Sequencer để lấy thông tin giao dịch mới nhất và chênh lệch giá từ nó. Chúng tôi thường nói đùa nội bộ rằng liệu Sequencer này có giống với Sở 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ở giao dịch chứng khoán New York nhanh chóng thu được dữ liệu giao dịch thông qua sợi quang và thực hiện các hoạt động định lượng. Liệu mô hình Sequencer này có khiến chúng ta thoái hóa thành một hệ thống rất tập trung không?

Tôi nghĩ làm thế nào để đạt được sự phân cấp 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 cơ chế proof-of-stake (POS) và kết hợp tính chất gốc của Lớp 2. Mã thông báo Được sử dụng làm bằng chứng về vốn chủ sở hữu. Bằng cách này, chúng ta có thể đạt được vòng quay Sequencer, tương tự như cuộc bầu cử người lãnh đạo an toàn hiện đang diễn ra trong 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.

Dorothy Liu:

Đối 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. Đầ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ó 4 đội gồm Arbitrum, Optimism, zkSync và Metis được mời. Trọng tâm cuộc thảo luận của họ chủ yếu là về việc mở rộng và hiệu suất. Tôi đã hỏi riêng họ về quan điểm của họ về lớp đồng thuận và liệu Rollup có cần thêm lớp đồng thuận hay không. Họ cho biết hiện tại họ chỉ đang xem xét việc mở rộng. Sự lạc quan ngay từ đầu đã không tính đến vấn đề này nên dù bây giờ có muốn thay đổi cũng 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 hoạt động Khai thác NFT, tất cả đều được tiến hành trực tiếp trên mạng chính Ethereum bằng cách sử dụng Sequencer phi tập trung. Theo quan điểm của 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ử. Làm thế nào họ có thể thay thế 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.

Giới thiệu Mã thông báo vấn đề, Arbitrum và Optimism đã chứng minh rằng có thể thực hiện được mà không cần đến chính họ Mã thông báo Nó có thể chạy. Nếu bạn muốn có Mã thông báo , một số thiết kế có thể được yêu cầu, 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 Stake và Slashing.

Cuối cùng, về MEV, mặc dù nó và Sequencer là hai chủ đề khác nhau nhưng chúng có liên quan 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 đã áp dụng 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 họ không thể giải quyết triệt để những vấn đề này. Chúng tôi cũng có thể đưa ra một số giải pháp MEV về phần cứng hoặc các khía cạnh khác, những giải pháp này sẽ được công bố trong tương lai.

Ye Zhang:

Chúng tôi đã thực hiện rất nhiều nghiên cứu về Sequencer và mặc dù kế hoạch cụ thể vẫn chưa được công bố nhưng chúng tôi thực sự đang làm việc chăm chỉ về mặt thiết kế. Hiện nay có hai hướng chính. Đầu tiên là giải pháp dựa trên Byzantine Fault Tolerance (BFT), chẳng hạn như sử dụng Tendermint để chọn một nhà lãnh đạo thay thế Sequencer tập trung trước đó. Phương pháp này yêu cầu đặt cọc và chém, đồng thời có thể yêu cầu phát hành của riêng bạn Mã thông báo để triển khai 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 tốt cho người dùng.

Lựa chọn thứ hai hứa hẹn hơn là Đấu giá MEV. Sự lạc quan lần đầu tiên đề xuất khái niệm đấu giá MEV, tức là ai trả giá cao nhất sẽ có được quyền sản xuất 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 tính phí tăng giá điên cuồng.

Các giải pháp tương tự bao gồm Base Rollup do Justin Drake đề xuất trước đây. Ý tưởng cốt lõi là sử dụng lại trình xác thực của Lớp 1 để tạo ra các khối Lớp 2. Bằng cách này, người xác thực xây dựng khối Lớp 1 và Lớp 2 có thể đặt các giao dịch xác minh của Lớp 2 vào các khối của Lớp 1 khi xây dựng các khối của Lớp 1, làm cho giá thầu tổng thể lớn hơn các khối của Lớp 1. Các bản cập nhật được bao gồm trước tiên. Ưu điểm của sơ đồ này là 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à 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 tồi tệ hơn.

Do đó, hướng đi hứa hẹn nhất hiện nay là các giải pháp dựa trên việc sử dụng lại trình xác thực Lớp 1 và các giải pháp dựa trên BFT. Chúng tôi đang nỗ lực giải quyết các vấn đề theo 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.

Cũng có một số hướng liên quan đến Sequencer phi tập trung, chẳng hạn như Flashbots và những người khác đã đề xuất một giải pháp có tên là Shared Sequencer, giải pháp này cũng có sẵn trong Superchain của Optimism. . Ý 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, đạt được MEV chuỗi chéo và cải thiện trải nghiệm UI chuỗi chéo. Tuy nhiên, giải pháp thiết kế này vẫn đang ở giai đoạn đầu và chưa giải quyết được một số vấn đề chính, chẳng hạn như vấn đề áp lực nút Sequencer và vấn đề nguyên tử của các giao dịch xuyên chuỗi.

Bộ tuần tự dùng chung 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ỏ), vì những ứng dụng này có thể không có đủ sức mạnh để điều hành mạng lưới phi tập trung. Tuy nhiên, đối với các ứng dụng tài sản thời gian thực lớn, việc thuyết phục chúng sử dụng trình sắp xếp chuỗi dùng chung có thể là một thách thức.

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

Về việc có cần Token hay không, 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 bạn sử dụng thuật toán BFT, rất có thể bạn sẽ cần mã thông báo, nhưng nếu bạn sử dụng phương pháp tiếp cận dựa trên trình xác thực Lớp 1 hiện có, bạn có thể không nhất thiết cần mã thông báo vì bạn có thể sử dụng lại tài nguyên của người khác. Bằng cách này, nguồn giá trị sẽ trở thành người đặt cược cho bạn và MEV sẽ chuyển trực tiếp đến người xác thực mạng. Do đó, câu hỏi Lớp 2 xem giá trị bổ sung của MEV như thế nào là yếu tố quyết định.

Về cách xử lý MEV, có quan điểm cho rằng việc sắp xếp hợp lý có thể giải quyết vấn đề MEV ở một mức độ nhất định, nhưng thực tế nó chỉ có thể làm nhẹ bớt MEV vấn đề. Bởi vì có thể vẫn có nhiều bot khác nhau cạnh tranh quyền ưu tiên nên tình hình cũng tương tự như các công ty thương mại truyền thống. Mặc dù một số tính năng ngẫu nhiên đã được đưa ra nhưng vấn đề 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 đã lưu ý 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ô hình tấn công, các nhà nghiên cứu đã chứng minh rằng trong trường hợp sắp xếp 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 có các chiến lược xếp hạng khác nhau cho các ứng dụng khác nhau.

Có rất nhiều nỗ lực thú vị. Ví dụ: giao dịch được mã hóa thông qua công nghệ mã hóa (như VDF) và được giải mã sau khi giao dịch được xác nhận. Điều này khiến không thể dự đoán trước giao dịch sẽ diễn ra như thế nào. Ngoài ra còn 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ố hướng đi chung nhưng mỗi hướng lại có nhiều vấn đề khác nhau. Vì vậy, chúng tôi mong muốn tiến hành phân tích kỹ càng trước khi hoàn thiện phương án để đảm bảo tính ổn định của phương án. Sequencer liên quan đến nhiều vấn đề như dòng giá trị, vì vậy chúng tôi tin rằng chưa có giải pháp hoàn hảo nào. Đây là lý do tại sao chúng tôi đưa nghiên cứu về Sequencer sau này.

Ngày nay, người ta thường tin rằng 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 phần thảo luận hôm nay, việc bắc cầu thực sự đả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 nối sẽ quy định rằng nếu bạn không thực hiện một giao dịch nhất định, bạn có thể phải chịu một số tác động trong 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 đó, khả năng 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ể khai thác của thợ mỏ (MEV). Ví dụ: Arbitrum hiện thực hiện chính sách đến trước được phục vụ trước bằng cách sử dụng trình sắp xếp tập trung. Quan điểm trước đây là nếu phát hiện tôi bị lợi dụng ở MEV thì có thể tôi sẽ rời khỏi mạng, khiến mọi người không tin tưởng 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 khởi động và các hiệu ứng mạng dần dần xuất hiện, chẳng hạn như một trình tự sắp xếp duy nhất, khi hệ sinh thái phát triển đến một quy mô nhất định và bạn bắt đầu tính phí hoặc xem xét MEV, người dùng thực sự đã trở nên rất phụ thuộc vào bạn. để họ chuyển sang nền tảng khác. Vì vậy, tôi nghĩ mối đe dọa đó có thể xuất hiệ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òn có các vấn đề về tuân thủ. nếu là của bạn Mã thông báo Liên quan đến Bằng chứng cổ phần (PoS), bạn có thể phải đối mặt với một số rủi ro tuân thủ nhất định. Ví dụ: nếu bạn triển khai tập trung hóa và một quốc gia nhất định yêu cầu bạn tắt trình sắp xếp thứ tự hoặc giải quyết một số vấn đề nhất định, thì việc phân cấp có thể mang lại những lợi ích nhất định.

Vì vậy, chúng tôi đã tiến hành phân tích rất chi tiết và đầu tư rất nhiều tâm huyết theo hướng này. Nếu khán giả có ai 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ân tài trong lĩnh vực này và sẽ đưa ra phân tích chi tiết hơn sau.

Jolestar:

Mọi người đã đạt được sự đồng thuận về việc giới thiệu BFT dưới dạng Trình sắp xếp chuỗi. Trên thực tế, chúng tôi cần giới thiệu sự đồng thuận BFT ở Lớp 2. Điều chúng tôi tập trung vào là nội dung của quyết định đồng thuận này. 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 kết quả. 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 nghĩ về Sequencer từ một góc độ khác. Mục đích chính của chúng tôi là gì? Một là vì sự an toàn. Trong các giải pháp Lớp 2, Trình sắp xếp thứ tự và các giải pháp khác như Người đề xuất hoặc Nhà cung cấp hoặc zk tương tự, chúng có các vai trò khác nhau. Sequencer và Proposer tách biệt nhau trong tình huống thao tác, nếu muốn gian lận thì phải gian lận cùng nhau. Ví dụ: Sequencer ẩn các giao dịch và Proposer tạo gốc giả. Nếu vai trò của họ được tách biệt và đảm nhận bởi các tổ chức khác nhau thì an ninh sẽ được đảm bảo.

Trước khi Bộ sắp xếp thứ tự được gửi đến Lớp 1, Bộ sắp xếp thứ tự có thể điều chỉnh thứ tự giao dịch và có thể có chỗ cho gian lận. Để loại bỏ vấn đề này, chúng tôi yêu cầu Trình sắp xếp trình tự 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 thực hiện thỏa thuận, đưa ra cam kết. Nếu trình tự chuỗi cuối cùng không phù hợp với lời hứa, Trình sắp xếp chuỗi có thể bị thách thức và bị trừng phạt.

Cuối cùng, nếu chúng ta thực sự muốn giới thiệu bỏ phiếu BFT, chúng ta nên quyết định thứ tự giao dịch chứ không phải kết quả giao dịch. Cơ chế đồng thuận hiện tại xác định kết quả bỏ phiếu thực hiện cuối cùng và không xác định trình tự giao dịch của blockchain. 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ề trật tự hoặc công bằng và để mọi người bỏ phiếu theo thứ tự giao dịch. Đây là hướng đi mà chúng tôi hiện đang khám phá và là giải pháp phân cấp với Sequencer.

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

Zhixiong Pan:

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

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

Jolestar:

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 giải pháp Tổng hợp ban đầu. Chúng tôi luôn tìm kiếm giải pháp để có TPS cao hơn và mức phí thấp hơn, nhưng chỉ dựa vào EIP-4844 thì không thể giải quyết được 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 hàng trăm nghìn hoặc gần 100.000 TPS, thì các giao dịch ở lớp đầu tiên vẫn không thể được đặt trực tiếp trên một khối.

Do đó, mục tiêu của chúng tôi hiện nay là đạt được một mô hình có thể kết hợp các giải pháp khác nhau nhằm đạt được chi phí thấp hơn, tính dễ sử dụng và thông lượng lớn hơn. Hãy chọn giữa các tùy chọn.

Dorothy Liu:

Trước hết, 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, nhưng có thể khó khăn hơn đối với zkEVM. Zhang Ye có thể cung cấp cho bạn câu trả lời chuyên nghiệp về lầ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, người sáng lập tên là Keone, người mà bạn có thể theo dõi trên Twitter. Keone, cựu nhà phát triển Jump, là một thiên tài toán học và giỏi tính toán. Ông đăng dự đoán trên Twitter về việc ra mắt giao thức EIP-4844, dự đoán 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 còn là vấn đề quan điểm. Liệu có chỗ để cải thiện phương pháp tính toán của anh ấy hay không cũng 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. Cuối cùng, nó vẫn phụ thuộc vào sự kết hợp giữa EIP-4844 và Rollup và có thể cần nhiều Rollup để cải thiện hiệu suất. EIP-4844 tự nó không giải quyết được nhiều vấn đề.

Đối với chúng tôi, dịch vụ 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 (như trò chơi và Giao thức DeFi) yêu cầu cao thông lượng nhưng không yêu cầu khả năng kết hợp cao, chúng có thể chạy trên Rollup. Các bản tổng hợp này sẽ chia sẻ một mạng Trình sắp xếp phi tập trung, đồng thời các mạng Nhà cung cấp và Trình xác thực cũng sẽ được phi tập trung. Đây là tầm nhìn hiện tại của chúng tôi đối với dịch vụ và chúng tôi sẽ cung cấp thêm thông tin chi tiết vào tháng tới. Do đó, chúng tôi tin rằng EIP-4844 hiện tại hoặc một giải pháp Tổng hợp duy nhất không thể giải quyết được mọi vấn đề. Việc dựa vào số lượng lớn Bản tổng hợp để cung cấp dịch vụ cho các dự án và kịch bản ứng dụng khác nhau chính là chìa khóa.

Ye Zhang:

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 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 thực hiện một mức độ nén nhất định trước khi tải lên, trong khi zkSync và StarkWare 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 số 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 số chi phí nhất định. Nhưng nếu chi phí dữ liệu giảm hơn nữa sau EIP-4844 hoặc phân đoạn, chúng tôi vẫn ưu tiên tải trực tiếp dữ liệu giao dịch gốc lên chuỗi 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à nhận đượ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 giảm xuống, chúng tôi có thể thêm một số thuật toán nén để đạt được hiệu quả tương tự như State Diff. Nhưng hiện tại chúng tôi thích sử dụng dữ liệu thô giao dịch hơn. Về 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ây cầu của chúng tôi. Chúng tôi đã bắt đầu khám phá các thiết kế cầu mới theo EIP-4844. Sẽ có một số tác động và cần phải viết một thông số kỹ thuật mới. . Phần còn lại nằm bên trong mạch của chúng ta (Mạch), vì theo định dạng mới, chúng ta không thể truy cập trực tiếp vào dữ liệu trước đó và chỉ có thể truy cập vào một cam kết nhỏ (Cam kết), vì vậy 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 sẽ có chi phí cho mạch điện, nhưng chúng tôi nghĩ điều đó là có thể thực hiện được.

Việc triển khai EIP-4844 sẽ liên quan đến vấn đề về miền vì dữ liệu nằm trên một đường cong khác và có thể không giống với định dạng dữ liệu gốc. Cách đây rất lâu, Vitalik đã đề xuất khái niệm chứng minh tính tương đương, nhưng sau đó nhận thấy rằng vẫn sẽ có một số vấn đề nếu các miền khác nhau. Dankrad và Vitalik đề xuất một cách phức tạp để kết hợp sự cởi mở đã cam kết vào các mạch. Chúng tôi tin rằng sự thay đổi này mang tính quyết định và sẽ mất thời gian, nhưng không đặc biệt phức tạp và khả thi. Chúng ta cần phối hợp khi nào Lớp 1 sẽ thực hiện thay đổi này và sau đó chúng ta có thể đ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 của mình.

Tề Châu:

Nghiên cứu sâu rộng đã được tiến hành trên EIP-4844. Trên thực tế, mục đích của EIP-4844 không phải là mở rộng công suất mà là triển khai 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à Data Hash của nó. Data Hash có thể truy cập được trong hợp đồng, triển khai các khái niệm này trước thời hạn để không cần nâng cấp hợp đồng khi triển khai Danksharding. EIP-4844 sẽ không mang lại cải tiến đáng kể so với phương thức tải lên dữ liệu 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ùng mức độ lớn.

Tuy nhiên, theo thông số kỹ thuật của Danksharding, thông lượng vào khoảng 20 lần. Vì vậy, giả sử chúng tôi đạt được 100 TPS trên EIP-4844, sử dụng Danksharding về mặt lý thuyết chúng tôi có thể đạt 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 việc nâng cấp EIP-4844 vì sau khi được nâng cấp, các nâng cấp Ethereum lớn tiếp theo sẽ không yêu cầu 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, hợp đồng này thực sự có thể đơn giản hơn về mặt 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 cung cấp dữ liệu. Ethereum hiện có các 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 ta cần thực hiện một số thử thách để chứng minh liệu những giao dịch này có đúng hay không.

Chúng tôi dự định cung cấp một số thư viện chung, tương tự như thư viện OpenZeppelin, để tạo điều kiện thuận lợi cho mọi người thực hiện các thao tác khác nhau trên blob 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ề mặt kiểm toán và tiêu thụ gas.

Tóm lại, EIP-4844 có tính đổi mới 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.

Chủ đề 4: Blockchain mô-đun

Trí Hùng Bàn:

Chủ đề cuối cùng là thảo luận về blockchain mô-đun với mọi người, đây là một chủ đề nóng và liên quan chặt chẽ đến chính chuỗi công khai, 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 quan điểm lớn hơn hiện nay là blockchain có thể dần dần phân thành các lớp như đồng thuận, thực thi, DA hoặc thanh toán. Trong bối cảnh đó, 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 cũng như 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.

Jolestar:

Tôi nghĩ chuỗi khối mô-đun là sự phát triển của các ý tưởng Lớp 2. Vì ở Lớp 2, chúng ta đã chuyển việc thực thi từ Lớp 1 sang Lớp 2, tại sao chúng ta không thể 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 giới thiệu một góc nhìn khác, đó là lấy các hệ thống phân tán truyền thống làm ví dụ, trong các 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 này tương đương với Lớp 1 trên blockchain. Nhưng Lớp 1 của blockchain khác với lớp đồng thuận truyền thống. Lớp 1 của blockchain 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 chúng tôi nhận thấy rằng hiệu quả thực thi đồng thuận toàn cầu quá chậm và chúng tôi cần phải chuyển nó ra ngoài để đạt được khả năng mở rộng.

Một góc nhìn khác là từ góc độ ứng dụng, khi 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 thiện 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ế, đây là việc chúng tôi xây dựng ứng dụng chứ không phải MySQL đang mở rộng quy mô Zookeeper. Ý tưởng chuỗi khối mô-đun này có thể giới thiệu một góc nhìn mới về cách chúng ta có thể sử dụng 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 để xây dựng DApp cơ bản.

Quan điểm mới này không xung đột với các chuỗi công cộng và các thành phần hệ thống sản xuất hiện có. Chúng tôi tin rằng trước tiên các nhà phát triển cần chọn một ngôn ngữ phù hợp để xây dựng ứng dụng để đảm bảo tính chắc chắn và có thể 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 ứng dụng và sau đó nghĩ 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 nó đòi hỏi khả năng phân cấp. 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. Vẫn tập trung, nhưng ít nhất có thể kiểm chứng được. Sau đó, một giao thức có thể được đưa vào để đảm bảo an ninh như một cam kết. 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.

Dorothy Liu:

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 này đã phát triển từ các giao thức béo và ứng dụng mỏng đến các ứng dụng béo và giao thức mỏng. Trọng tâm bây giờ chuyển từ việc theo đuổi những điều không tưởng và tiến bộ công nghệ phi tập trung sang các kịch bản ứng dụng thực tế. Với sự xuất hiện 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 đang chú ý hơn đến những gì ứng dụng blockchain có thể đạt được, thay vì chỉ mở rộng Ethereum hoặc thúc đẩy 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 sự đánh đổi trong kỷ nguyên đa chuỗi.

Là một công ty hoặc nhóm theo đị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 có thể xây dựng được một giải pháp công nghệ mang phong cách Lego có thể tháo rời và lắp ráp để đáp ứng nhu cầu của các ứng dụng khác nhau. Một số ứng dụng có thể cần 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 vào Celestia hoặc tương thích với EigenLayer. Chúng tôi muốn cung cấp 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 dựa trên nhu cầu của họ. Chúng tôi có thể đặt L1 trên Ethereum hoặc Chuỗi BNB hoặc thậm chí Solana hoặc Lớp Beacon của riêng chúng tôi. Từ góc độ 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 không nhất thiết phải có trên Ethereum. Việc tách khỏi cơ quan giao dịch của Ethereum sẽ giảm đáng kể chi phí.

Trong thời đại của các ứng dụng béo bở này, chúng tôi tập trung vào cách cung cấp cho mỗi ứng dụng giải pháp mở rộng phù hợp nhất, thay vì chỉ tối ưu hóa hướng đi. Đối với cuộc 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í của bộ kiểm chứng của zkEVM. Ví dụ: Scroll có thể cần chi 10.000 USD mỗi tháng để chạy bộ kiểm chứng, đ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 Prover rẻ hơn và chúng tôi có thể cung cấp giải pháp sử dụng máy tính để thực hiện Prover, cung cấp các giải pháp kỹ thuật khác nhau tùy theo nhu cầu khác nhau. Đây là giải pháp của chúng tôi.

Tề Châu:

Từ góc độ lịch sử, tôi đồng ý với hướng phát triển mô đun hóa. Đ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. Nghĩ về Ethereum hoặc blockchain như một máy tính thế giới, chúng ta có thể học hỏi từ các hệ thống máy tính hiện có để phát huy tốt hơn vai trò của nó. Ví dụ, vì mỗi thành phần có giá trị thị trường rất lớn nên Lớp 1 của Ethereum có thể được so sánh với CPU đời đầu, với sức mạnh tính toán cơ bản và khả năng lưu trữ hạn chế. DA, mặt khác, giống trí nhớ hơn.

Giữa bộ nhớ và CPU, chúng ta cần băm dữ liệu và biên dịch trước để 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 cho các thiết bị điện toán hiệu suất cao như GPU. Trong mạng blockchain, việc truyền dữ liệu tính toán được thực hiện thông qua các phương pháp như DA và bằng chứng không có kiến thức. Ngoài ra, chúng ta cần rất nhiều dung lượng lưu trữ để sao chép dữ liệu từ bộ nhớ vào đĩa cứng. Cuối cùng, chúng ta 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 ta sử dụng hiện nay.

Học từ các hệ thống máy tính trưởng thành và học 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 ổ 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 thì 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.

Một máy tính không có CPU và bộ nhớ thì không thể khởi động được, đây là bộ phận rất quan trọng. Với những 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 lại với nhau. 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 cách tiếp cận mô-đun để kết nối với 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 được kết nối với Lớp 2, EthStorage thực sự trở thành Lớp 3 ở một mức độ nhất định. Đây là tầm nhìn của chúng tôi về kiến trúc tổng thể của máy tính hoặc chuỗi khối trong thế giới tương lai.

Ye Zhang:

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

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 phụ thuộc vào lựa chọn của chính bạn, việc bạn chọn nút đầy đủ hay nút nhẹ. Ví dụ: Optimistic Rollup 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". Thực sự, tất cả những thông tin tổng hợp này chỉ nhằm mục đích thiết lập quan điểm về việc liệu tôi có tin tưởng vào dữ liệu của bạn hay không và liệu tôi có tin tưởng vào việc chuyển tiền từ bạn sang tiền của bạn hay không.

Vì vậy, ít nhất đối với chúng tôi, chúng tôi muốn nền tảng của mình luôn tin tưởng vào lớp dữ liệu Ethereum và tiếp tục là một Bản tổng hợp. Chúng tôi cũng sẽ làm việc chăm chỉ để thúc đẩy quá trình phân chia dữ liệu. Tôi nghĩ điều duy nhất cần tập trung vào là thời điểm nó sẽ xảy ra và mất bao lâu. Chúng ta có cần thực hiện các biện pháp chuyển tiếp trước khi điều này xảy ra 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 cho việc phân chia dữ liệu. Nếu chúng tôi ước tính sẽ mất 5 năm để đạt được mục tiêu thì chúng tôi có thể thực hiện một số bước trung gian. Nhưng nếu chúng tôi nghĩ điều đó sẽ xảy ra trong một khung thời gian hợp lý thì chúng tôi vẫn sẽ đi theo hướng đó.

Tính mô-đun hóa quá mức có thể không phải là điều tốt. Khi chúng ta xem xé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ể nâng cấp được hay không, Trình sắp xếp chuỗi có được phân cấp hay không, liệu nó có phải là nguồn mở hay không và liệu nó có đượ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ể nâng cấp, nếu một bản tổng hợp không tuân thủ thực sự gây ra điều gì đó xấu thì nó có thể bị phát hiện ngay lập tức. Nếu công chúng không biết về đặc tính của các bản tổng hợp khác nhau và sự đánh đổi giữa chúng, đồng thời đã có 100 bản tổng hợp để lựa chọn thì một số vấn đề bảo mật có thể phát sinh. Do đó, tôi nghĩ rằng cuối cùng có thể có một số Bản tổng hợp chính cung cấp tính bảo mật tuyệt đối và mọi người đều có những đảm bảo nhất định về các thuộc tính của nó, đồng thời có khả năng kết hợp tốt. Trên cơ sở này, cho dù đang 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 đó, đều có thể giảm bớt áp lực cho Lớp 2. Lúc này, họ có thể lựa chọn sử dụng các lớp dữ liệu khác hoặc các phương pháp khác, chỉ cần cộng đồng đạt được sự đồng thuận, họ có thể đổi mới theo ý tưởng của mình.

Tuy nhiên, chúng tôi hy vọng sẽ là Lớp 2 đáp ứng tốt nhất nhu cầu của cộng đồng và hỗ trợ một số nghiên cứu cũng như thúc đẩy một số tiến bộ kỹ thuật. Chúng tôi muốn nền tảng của mình tuyệt đối an toàn, phi tập trung tuyệt đối và thực hiện tất cả các loại đổi mới trên cơ sở đó, cho dù đó là đổi mới điên rồ hơn hay bất cứ điều gì.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia