Vào ngày 12 tháng 10, các nhà phát triển Ethereum đã tập trung để tham gia cuộc gọi hội nghị Zoom. Cuộc họp do Tim Beiko, người đứng đầu bộ phận hỗ trợ giao thức tại Ethereum Foundation chủ trì, là nơi các nhà phát triển thảo luận và điều phối các thay đổi đối với Lớp thực thi Ethereum (EL). Cuộc họp mới nhất tập trung vào thử nghiệm Dencun và phát triển định dạng đối tượng EVM.

Vào ngày 12 tháng 10, các nhà phát triển Ethereum đã tập trung trên Zoom cho cuộc họp Cuộc gọi số 172 của All Core Developers Execution (ACDE). Cuộc gọi hội nghị ACDE là chuỗi cuộc họp hai tuần một lần do Tim Beiko, Trưởng bộ phận Hỗ trợ Giao thức tại Ethereum Foundation tổ chức, nơi các nhà phát triển thảo luận và điều phối các thay đổi đối với Lớp thực thi Ethereum (EL). Tuần này, các nhà phát triển đang tập trung vào tiến độ của các chủ đề sau:

Xét nghiệm Cancun/Deneb (Dencun)

Phát triển định dạng đối tượng Máy ảo Ethereum (EVM).

Kiểm tra Dencun

Barnabas Busa, kỹ sư DevOps tại Ethereum Foundation, gần đây đã chia sẻ một số cập nhật về Devnet #9, được phát hành vào ngày 29 tháng 9.

Devnet #9 hiện có tỷ lệ tham gia là 93%, nghĩa là 93% người xác thực đang tích cực tham gia vào sự đồng thuận của mạng.

7% trình xác thực không chạy chủ yếu bao gồm các nút trình xác thực Geth (EL)/Teku (CL).

Ngoài ra còn có vấn đề với sự kết hợp máy khách Erigon (EL)/Prysm (CL) cũng như máy khách EthereumJS (EL).

Nhóm Flashbots đang thử nghiệm bộ chuyển tiếp và trình xây dựng MEV-Boost trên Devnet #9. Busa khuyến khích các nhà điều hành nhà xây dựng và chuyển tiếp khác liên hệ với anh ấy để có thể thử nghiệm nhiều cơ sở hạ tầng MEV hơn trên Devnet #9.

Giao dịch Blob chưa được thử nghiệm với trình tạo MEV-Boost. Trong trường hợp này, blob đã bị người xây dựng loại bỏ, nhưng các nhà phát triển vẫn chưa chắc liệu điều này là do blob thực sự không hợp lệ, không đáp ứng yêu cầu phí cơ bản tối thiểu hay bị loại bỏ vì một số lý do khác.

Busa và đồng nghiệp tại Ethereum Foundation Parithosh Jayanthi đã chia sẻ thông tin cập nhật về Devnet #10 sắp tới:

Devnet #10 chưa sẵn sàng trong tuần này nhưng dự kiến ​​sẽ sẵn sàng vào tuần tới.

Đối với Devnet #10, các nhà phát triển dự định thử nghiệm tệp cài đặt đáng tin cậy trong buổi lễ EIP 4844 KZG.

Devnet #10 sẽ có cơ sở trình xác thực lớn, bao gồm 330.000 trình xác thực đang hoạt động. Khi mạng phát triển mới được ra mắt, sẽ có một lượng lớn tiền gửi và rút tiền của người xác nhận, dự kiến ​​giới hạn vào và ra của người xác thực sẽ giảm từ 5 xuống 4 lần trong vòng một hoặc hai ngày sau khi mạng ra mắt. Mặc dù giới hạn kết nối đầu vào tối đa thực tế trên mạng chính là 8, nhưng các nhà phát triển sẽ áp dụng giới hạn 4 để kiểm tra EIP 7514 trên Devnet #10.

Busa nhấn mạnh rằng các nhà phát triển vẫn đang giải quyết một số vấn đề chính trong quá trình thử nghiệm của Dencun. Nhóm phát triển sẽ không khởi chạy Devnet #10 cho đến khi những vấn đề này được giải quyết hợp lý, đây có thể sẽ là devnet cuối cùng của Dencun trước khi bản nâng cấp được kích hoạt trên các mạng thử nghiệm Ethereum công khai như Goerli. Trong cuộc trò chuyện trên Zoom, Jayanthi đã nêu ra những vấn đề chính mà các nhà phát triển cần giải quyết trước khi ra mắt Devnet #10:

Cập nhật tệp cài đặt tin cậy cho lễ EIP 4844 KZG

Trực quan hóa tốt hơn các giao dịch blob

Cải tiến đường ống MEV

Cải thiện sự ổn định của mạng

Cập nhật tệp cài đặt tin cậy cho lễ EIP 4844 KZG

Trực quan hóa tốt hơn các giao dịch blob

Cải tiến đường ống MEV

Cải thiện sự ổn định của mạng

Trong cuộc gọi, Jayanthi đã khuyến khích các nhóm khách hàng thêm hỗ trợ cho API Beacon để tăng khả năng hiển thị của các giao dịch blob. Beiko hỏi liệu các nhà phát triển có sẵn sàng nâng cấp mạng thử nghiệm Goerli sau khi ra mắt Devnet #10 hay không. Busa khuyên bạn nên quan sát hiệu suất của Devnet #10 trước khi quyết định các bước thử nghiệm nâng cấp tiếp theo.

Ngoài ra, Jayanthi xác nhận rằng trong một khoảng thời gian sau khi ra mắt Devnet #10, các nhà phát triển có thể tiến hành một nhánh ngầm của mạng chính Ethereum cùng lúc với công việc thử nghiệm mạng thử nghiệm công khai để thử nghiệm thêm bản nâng cấp Dencun. Tuy nhiên, Jayanthi lưu ý rằng tính hữu ích của Shadow Fork có thể bị hạn chế vì hầu hết các lỗi được phát hiện trong quá trình thử nghiệm Dencun đều ở cấp độ mạng ngang hàng.

Nhà phát triển Geth (EL), Marius van der Wijden cho biết đồng nghiệp của ông là Péter Szilágyi đã chạy thành công nút riêng của mình trên Devnet #9 và phát hiện ra một vấn đề nghiêm trọng liên quan đến thư rác blob.

Được biết, để ngăn chặn sự cố nút, Szilágyi đã triển khai trình xử lý giao dịch để hạn chế số lượng đốm màu mà anh ta thấy trên mạng phát triển. Van der Wijden khuyến nghị nhóm CL nên xem lại mục tiêu/giới hạn blob tối đa 3/6 trong EIP 4844 và yêu cầu nhóm EL xem xét kỹ lưỡng các yêu cầu về băng thông nút cũng như cách giải quyết thư rác blob.

Để thảo luận thêm về những vấn đề này, Beiko khuyến khích các nhà phát triển tham dự cuộc gọi thử nghiệm khả năng tương tác Dencun vào ngày 16 tháng 10.

Phát triển định dạng đối tượng EVM

Sau đó, các nhà phát triển đã thảo luận về những phát triển mới nhất trong Định dạng đối tượng EVM (EOF). EOF là một tập hợp EIP tập trung vào các thay đổi đối với EVM, một máy ảo dựa trên Ethereum được sử dụng để thực thi mã hợp đồng thông minh. Danno Ferrin, một trong những người ủng hộ EOF, đã tóm tắt và tóm tắt công việc của EOF trong vài tháng qua.

Khi bắt đầu phần trình bày của mình, Ferrin nhấn mạnh rằng ông kỳ vọng EOF sẽ là một thay đổi mã lớn trong bản nâng cấp sau Cancun/Deneb (được gọi là Praha/Electra). Ferrin cho biết hiện có bốn nhóm chính làm việc về EOF:

Nhóm Ipsilon: Nhóm phát triển được Ethereum Foundation tài trợ, tập trung vào cải tiến EVM

Nhóm khách hàng EL: như Geth, Besu và Nethermind

Các nhóm biên dịch ngôn ngữ cấp cao: như Solidity và Vyper

Nhà phát triển hợp đồng thông minh: Ví dụ: những người ủng hộ opcode SSTORE2.

Nhìn chung, nhiều nhóm khác nhau đang đóng góp vào sự phát triển của EOF và cùng nhau thúc đẩy tiến bộ công nghệ của mạng Ethereum.

Mục tiêu chính của EOF là tạo định dạng vùng chứa mới cho mã EVM. Định dạng vùng chứa này sẽ phân tách rõ ràng mã và dữ liệu, điều này không thể thực hiện được ở các định dạng hiện tại. Nó cũng cho phép giới thiệu các opcode mới, giúp các nhà phát triển hợp đồng thông minh thiết kế các ứng dụng hiệu quả hơn và cung cấp bảo mật mã tốt hơn. EOF yêu cầu tạo định dạng vùng chứa mới cho mã EVM trong khi vẫn duy trì định dạng hiện có.

Để tạo điều kiện thuận lợi cho việc triển khai và thử nghiệm những thay đổi này xung quanh EVM, Ferrin đã trình bày chi tiết các cách mà các nhà phát triển có thể giảm sự phụ thuộc giữa các hợp đồng thông minh sử dụng mã EOF EVM mới và các hợp đồng thông minh cũ hơn không sử dụng. Mặc dù nhóm khách hàng cần duy trì hai phiên bản EVM nhưng Ferrin tin rằng phiên bản mới sẽ dễ cập nhật hơn EVM hiện tại. Ông cũng nói rằng theo thời gian, khi ngày càng có nhiều nhà phát triển hợp đồng thông minh áp dụng EOF, EVM hiện tại có thể dần trở nên lỗi thời.

Các EIP liên quan đến EOF được Ferrin đề cập trong bài phát biểu của mình bao gồm:

EIP 3540: Định dạng vùng chứa mới cho mã EVM.

EIP 4200: Ba hướng dẫn nhảy EVM mới giới thiệu các bước nhảy tĩnh.

EIP 4750: Hai mã hoạt động mới sẽ loại bỏ nhu cầu nhảy động và vô hiệu hóa chúng.

EIP 3540: Định dạng vùng chứa mới cho mã EVM.

EIP 4200: Ba hướng dẫn nhảy EVM mới giới thiệu các bước nhảy tĩnh.

EIP 4750: Hai mã hoạt động mới sẽ loại bỏ nhu cầu nhảy động và vô hiệu hóa chúng.

EIP 663: Hai hướng dẫn mới cho phép truy cập vào độ sâu ngăn xếp là 256 (thay vì 16).

EIP 7480: Bốn hướng dẫn mới để cho phép đọc phần dữ liệu của vùng chứa EOF.

EIP 7069: Ba hướng dẫn cuộc gọi mới để đơn giản hóa việc sử dụng gas và ngữ nghĩa liên quan đến chi phí.

EIP 5450: Giới thiệu xác minh hợp đồng thông minh định dạng EOF trong quá trình thực hiện hợp đồng.

EIP 3670: Giới thiệu xác minh hợp đồng thông minh định dạng EOF tại thời điểm tạo hợp đồng.

Để xem danh sách đầy đủ các thay đổi đối với opcode EOF, hãy xem biểu đồ sau từ phần trình bày của Ferrin.

Tóm tắt các thay đổi opcode EOF. Nguồn: Danno Fehling

Về tiến độ thử nghiệm EOF, Ferrin giải thích rằng do đặc tả EOF vẫn chưa được hoàn thiện nên đây là lý do tại sao chưa có khách hàng nào thực hiện nâng cấp. Tuy nhiên, ông hy vọng rằng việc thử nghiệm EOF sẽ rất "độc lập" và tương đối đơn giản, vì trọng tâm của EOF chỉ là những thay đổi được thực hiện đối với EVM. Ông nói: "Chúng tôi không cần phải lo lắng về tương tác mạng hoặc ghép nối với các kết hợp CL/EL khác nhau. Tôi không nghĩ chúng tôi sẽ cần cùng một cấp độ mạng phát triển và mạng thử nghiệm vì chúng tôi sẽ có thể thử nghiệm nó." ." Ferrin nói thêm: "Chúng tôi sẽ viết các bài kiểm tra tham khảo rõ ràng... Ngoài ra, một trong những lợi thế lớn mà chúng tôi có được là thử nghiệm EVM vi sai mà chúng tôi đang thực hiện."

Vào cuối bài nói chuyện của mình, Ferrin nhắc lại mong muốn coi EOF là một thay đổi mã lớn trong bản nâng cấp Praha/Electra. Ông cũng cho biết việc kiểm tra và thực hiện một loạt thay đổi mã cho EOF trên mạng chính trong vòng ba đến sáu tháng sau khi quá trình nâng cấp Dencun hoàn tất là khả thi. Bạn có thể tìm thấy thông số kỹ thuật mới nhất cho EOF tại đây . Các câu hỏi mở về các thông số kỹ thuật này đã được nhóm Ipsilon biên soạn tại đây . Một số phần của đặc tả EOF vẫn cần được tinh chỉnh. Các nhà phát triển tham gia cuộc gọi được khuyến khích chia sẻ suy nghĩ của họ về những phát triển và thông số kỹ thuật mới nhất cho EOF trong kênh "#EVM" trên Ethereum Research and Development Discord.

Tranh luận về định dạng đối tượng EVM

Bài thuyết trình của Ferrin đã làm dấy lên cuộc thảo luận rộng rãi giữa các nhà phát triển. Trong cuộc gọi hội nghị, mối quan tâm chính của các nhà phát triển về EOF là như sau:

Dòng thời gian: Một số nhà phát triển, bao gồm cả Tim Beiko, đã ngần ngại về mốc thời gian từ ba đến sáu tháng để triển khai EOF sau khi nâng cấp Dencun.

Khẩn cấp: Các nhà phát triển đang xem xét kết hợp Verkle vào Bragg/Electra trong một thay đổi mã lớn khác. Vào đầu tháng 8, nhà phát triển Guillaume Ballet của Ethereum Foundation đã chia sẻ tiến trình mới nhất của Verkle. Trong cuộc gọi hội nghị tuần này, Ballet nhấn mạnh rằng Verkle là bản nâng cấp khẩn cấp hơn cho Ethereum so với EOF và do đó cần được ưu tiên. Ballet cũng cho biết ông sẽ hỗ trợ nâng cấp nếu độ phức tạp của EOF có thể giảm xuống và số lượng thay đổi mã giảm xuống để việc triển khai nó không ảnh hưởng đến lịch trình của Verkle.

Lợi ích: Nhà phát triển Van der Wijden và Nethermind (EL) Lukasz Rozmej, trong số những người khác, đặt câu hỏi về sự cân bằng giữa lợi ích trước mắt của EOF và độ phức tạp của việc nâng cấp. Liên quan đến những lo ngại về việc thiếu nhu cầu mạnh mẽ đối với một sự thay đổi lớn như vậy đối với EVM, Ferrin nói rằng EVM đã được nhóm phát triển ban đầu của Ethereum viết “vào cuối tuần” và có thể thực hiện rất nhiều cải tiến để đảm bảo rằng EVM vẫn tồn tại. cạnh tranh với các đối thủ cạnh tranh, chẳng hạn như Sui thay thế chuỗi khối lớp 1 mới. “Đây không phải là một rủi ro bảo mật,” Ferrin nói. "Đó giống một giao dịch mang tính hiện sinh hơn."

Độ phức tạp và rủi ro gia tăng: Van der Wijden nhấn mạnh những cách mà EOF có thể làm tăng độ phức tạp và rủi ro của giao thức. Sẽ có gánh nặng gia tăng đối với các nhóm khách hàng trong việc duy trì cả hai phiên bản EVM và đảm bảo rằng sự phụ thuộc lẫn nhau của chúng được tính đến trong các đợt hard fork trong tương lai. Wijden tin rằng nhóm Lớp 2 không nên cố gắng "đẩy" công việc duy trì EVM và EOF song song cho nhóm khách hàng mà nên tập trung vào việc triển khai các cải tiến đối với EVM trên giao thức của riêng mình.

Khả năng tương thích ngược: Một vấn đề lớn khác với EOF là nó có thể gây ra các vấn đề về khả năng tương thích ngược đối với các hợp đồng thông minh cũ. EOF được thiết kế theo cách đảm bảo hỗ trợ liên tục cho các hợp đồng thông minh cũ không sử dụng bộ chứa EOF. Tuy nhiên, các nhà phát triển như Ferrin và nhà nghiên cứu Ansgar Dietrichs của Ethereum Foundation đã gợi ý rằng theo thời gian, chức năng hợp đồng thông minh cũ có thể bị loại bỏ và nâng cấp đặc biệt cho EOF.

Quản trị EVM: Dietrichs cũng bày tỏ lo ngại về tác động của EOF đối với quản trị EVM. Ethereum không ngừng phát triển để hỗ trợ thực hiện các hợp đồng thông minh trên các mạng thay thế được gọi là Lớp 2. Giả sử rằng trong tương lai, hầu hết hoạt động của người dùng và việc thực hiện hợp đồng thông minh diễn ra ngoài chuỗi và Ethereum chủ yếu được sử dụng làm lớp sẵn có của dữ liệu, thì những thay đổi đối với EVM sẽ là quan trọng nhất đối với các giao thức lớp 2 thay vì mạng chính Ethereum. Dietrichs khuyến nghị các nhà phát triển nên cân nhắc và thảo luận cẩn thận về cách họ quyết định thực hiện các thay đổi đối với EVM trong hệ sinh thái Lớp 2 đang mở rộng.

Ferrin và cộng sự bắt đầu nghiên cứu EOF từ đầu năm 2021. Đầu năm nay, EOF đã bị hard fork Thượng Hải từ chối do lộ trình gồm nhiều giai đoạn. Những người đề xuất EOF đã giải quyết vấn đề này bằng cách tạo ra một thiết kế cập nhật cho bản nâng cấp sẽ đưa vào tất cả các thay đổi liên quan đến EOF trong một bản nâng cấp lớn. Tuy nhiên, sự phức tạp của bản nâng cấp này là một trong những mối quan tâm chính về EOF được nêu ra trong cuộc gọi hội nghị tuần này. Van der Wijden nhấn mạnh rằng lần này các nhà phát triển nên xem xét cẩn thận liệu EOF có nên được triển khai trên Ethereum hay không, thay vì tiếp tục trì hoãn các quyết định về EOF.

"Tôi biết nhóm Ipsilon và Danno đã dành rất nhiều thời gian để giải quyết vấn đề này, và thật khó để nói rằng chúng tôi có thể sẽ không cung cấp được nó sau một thời gian dài, nhưng tôi nghĩ sẽ còn tệ hơn nếu nói, 'Hãy xem, ' và sau đó chúng tôi đã bị trì hoãn trong hai năm và sau đó chúng tôi nói, 'Ồ, rốt cuộc thì chúng tôi sẽ không giao nó.' Vì vậy, tôi nghĩ chúng ta nên đưa ra quyết định về Devconnect,” van der Wijden nói và nói thêm, “ Nếu đó là điều chúng tôi muốn làm thì chúng tôi sẽ làm, trừ khi có thách thức kỹ thuật tương tự, nếu chúng tôi nói đây là điều chúng tôi sẽ không làm thì chúng tôi sẽ làm. Tôi không nghĩ điều đó sẽ xảy ra, vì tất cả những công việc khó khăn đã được thực hiện. Chỉ công bằng cho cả nhóm khi mọi người đưa ra quyết định rõ ràng.”

Rozmej nói thêm rằng ngoài EOF và Verkle, các nhà phát triển có lẽ nên xem xét lại các thay đổi mã như EIP 4444 để giải quyết vấn đề ngày càng tăng về tăng trưởng dữ liệu chuỗi lịch sử. Theo Rozmej, tốc độ tăng trưởng dữ liệu chuỗi lịch sử là 20GB mỗi tháng. Beiko đồng ý rằng các nhà phát triển nên tiếp tục thảo luận về EOF, Verkle và Prague/Electra trên Devconnect. Beiko cũng nhấn mạnh rằng Thứ Tư, ngày 18 tháng 10, sẽ dành riêng cho việc triệu tập các giao thức Lớp 2 giống EVM để khuyến khích sự hợp tác giữa các nhóm này. Cũng sẽ có cuộc gọi hội nghị dành cho những người triển khai EOF vào cùng ngày. Cuối cùng, Beiko đã đề cập đến sự kiện Layer2 Day dành riêng do L2Beat tổ chức tại Devconnect.