Đề xuất cải tiến Ethereum và Đề xuất cải tiến quy trình nâng cấp

Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans)Lưu ý của biên tập viên: Bài viết này đến từ

, Tác giả: Tim Beiko, bản dịch & hiệu đính: Peter Chen & A Jian, được Odaily tái bản với sự ủy quyền.

Bản tóm tắt

Bài đăng này là bản ghi sơ bộ cuộc trò chuyện giữa Danno Ferrin và tôi tại DevconV (Hội nghị các nhà phát triển Ethereum lần thứ 6). Bài viết thảo luận về một số đề xuất cải tiến quy trình EIP do cộng đồng đưa ra trong năm qua và kết hợp chúng thành một khuôn khổ thống nhất để hướng dẫn chúng tôi cách nâng cấp Ethereum thuận lợi hơn. Chúng tôi gọi đó là “mô hình nhà ga”.

• tiêu đề phụ

• Bản tóm tắt

• Dựa trên một số đề xuất từ ​​cộng đồng trong năm qua, chúng tôi đề xuất một phương pháp mới để phối hợp nâng cấp trên mạng Ethereum. Cụ thể, chúng tôi tin rằng:

• Việc nâng cấp nên diễn ra hai lần một năm để cung cấp khả năng dự đoán rõ ràng cho cộng đồng;

Các bản nâng cấp chỉ nên chứa các Đề xuất cải tiến Ethereum (EIP) đã sẵn sàng để phát hành và bất kỳ cải tiến nào vẫn đang được thảo luận nên được đưa vào bản nâng cấp tiếp theo và không trì hoãn bản nâng cấp hiện tại;

Các đề xuất cải tiến Ethereum nên được phát triển bởi các nhóm làm việc một cách độc lập và chỉ nên được xem xét để đưa vào các bản nâng cấp khi hoàn thành;

Các đề xuất cải tiến Ethereum và các nhóm làm việc nên có một người đứng đầu hoặc đại diện để liên hệ với cộng đồng và trả lời các câu hỏi của cộng đồng về EIP có liên quan.

Hãy nói sơ qua về lịch sử nâng cấp của Ethereum. Một số nâng cấp mạng đầu tiên, bao gồm Frontiers, Homeland, Byzantium và Constantinople, giống như một kỳ nghỉ gia đình vào những năm 1950, nơi bố mẹ sẽ mở đồ trong xe và chúng tôi sẽ nhảy vào băng ghế sau và có thể mang theo những món đồ chơi yêu thích của chúng tôi. họ sẽ đưa chúng ta đến đích an toàn.

Đây là một sự tương tự đơn giản đối với các bản nâng cấp trong quá khứ, nhưng đối với những bản nâng cấp này, các nhà phát triển cốt lõi đã viết hầu hết các đề xuất cải tiến Ethereum và cộng đồng Ethereum đủ nhỏ để họ có thể giao tiếp với cộng đồng một cách có tổ chức và có kế hoạch, tạo ra The ngã ba và nâng cấp diễn ra suôn sẻ.

….Nhưng cũng có lúc bận quá! Trong một vài trường hợp chúng tôi phải lao vào chữa cháy. Trong những dịp đó, về cơ bản chúng tôi đều là những người lính. Cho dù đó là một cuộc tấn công mạng trong Devcon 2 ở Thượng Hải, một fork Ethereum do The DAO gây ra hay một điểm yếu được phát hiện vào phút cuối trước khi nâng cấp Constantinople, cộng đồng luôn cùng nhau sửa lỗi, giải quyết vấn đề và để Người dùng nâng cấp các nút của họ kịp thời .

Mô tả hình ảnh

-Một thác nước màu ethereum-

Cho đến bây giờ nâng cấp Istanbul. Khi chúng tôi bắt đầu lập kế hoạch nâng cấp, chúng tôi đã nắm rõ quy trình làm việc của mình và quyết định lập kế hoạch cho quá trình nâng cấp kỹ lưỡng hơn. Chúng tôi đã thiết lập một nút thời gian cho từng giai đoạn của quá trình nâng cấp và đã lập kế hoạch chi tiết từ đề xuất cải tiến Ethereum cho đến nâng cấp mạng chính cuối cùng. Trước khi chúng tôi biết điều đó, chúng tôi đã ở trong một loại mô hình thác nước Ethereum!

Tuy nhiên, có bao nhiêu trong số các nút thời gian theo kế hoạch này thực sự được hoàn thành đúng hạn? Chỉ có một, và đó là lúc bắt đầu.

Nhiều điều đã sai trong quá trình thực hiện. Một trong những lý do quan trọng hơn là cộng đồng Ethereum đã phát triển rất nhiều kể từ lần nâng cấp cuối cùng và khi đến lúc bắt đầu xem xét đề xuất nâng cấp Istanbul, các nhà phát triển cốt lõi đã phải đóng gói cùng nhau hơn 30 đề xuất cải tiến Ethereum Đọc, không chỉ một số ít các đề xuất để bình luận về!

Mô tả hình ảnh

Khi chúng tôi nhận được danh sách các đề xuất cải tiến cuối cùng cho Ethereum Istanbul thì đã là giữa mùa hè.Theo kế hoạch ban đầu, chúng tôi lẽ ra phải hoàn thành việc triển khai ứng dụng khách vào thời điểm này. Khi điều này xảy ra, rất nhiều người nhận ra rằng quá trình phát triển chậm hơn nhiều so với mong đợi và rất nhiều đề xuất đã được đưa ra về cách chúng tôi có thể làm cho quá trình nâng cấp Berlin sau Istanbul diễn ra suôn sẻ hơn. Bây giờ chúng ta sẽ thảo luận về một số đề xuất này và sau đó kết hợp chúng vào cái mà chúng ta gọi là "mô hình nhà ga".

Mô tả hình ảnh

tiêu đề phụ

Ethereum 1.X sẽ cố gắng thay đổi quy trình phát triển EIP

Trong quá trình nâng cấp Istanbul, người đầu tiên cố gắng giải quyết vấn đề về quy trình phát triển là Alexey Akhunov. Anh ấy đã viết một bài đăng trên blog (Ghi chú của biên tập viên: xem siêu liên kết ở cuối bài viết để biết bản dịch tiếng Trung) mô tả cách chúng tôi có thể sử dụng ReTestEth để tăng số lượng thành viên đóng góp vào việc cải tiến giao thức Ethereum bằng cách thành lập một nhóm làm việc, đồng thời giảm gánh nặng cho các nhà phát triển cốt lõi hiện tại. Trong quy trình cải tiến "tiền 1.x", đề xuất cải tiến Ethereum đã gửi sẽ chủ yếu được thực hiện bởi các nhà phát triển khách hàng của Geth, Parity và Aleth, trong trường hợp đó, đề xuất cải tiến Ethereum sẽ được các nhóm này cộng tác cải thiện. Khi khách hàng đã đồng ý về thông số kỹ thuật cuối cùng của đề xuất cải tiến Ethereum, các thử nghiệm tham khảo có thể được tạo. Aleth là ứng dụng khách duy nhất có thể tạo các thử nghiệm, vì vậy để tạo các thử nghiệm này, tất cả các đề xuất cải tiến Ethereum cần được triển khai trong Aleth. Sau đó, nhóm thử nghiệm của EF sẽ chạy các thử nghiệm này và viết các thử nghiệm tuân thủ mà tất cả các máy khách sẽ chạy.

-Hình ảnh trên slideshow được lấy từ bài đăng gốc của Alexey-

Có một số nút cổ chai trong quy trình này: nhóm triển khai ứng dụng khách chính, Aleth tạo các bài kiểm tra tham chiếu và các bài kiểm tra tuân thủ do nhóm kiểm tra của EF viết. Để nâng cao hiệu quả công việc, Alexey đề xuất ý tưởng thành lập một nhóm làm việc. Các nhóm làm việc này sẽ được tạo thành từ một nhóm nhỏ những người có chung mong muốn cải thiện Ethereum. Họ có thể bắt đầu từ giai đoạn đầu của một đề xuất cải tiến Ethereum và giúp tinh chỉnh nó để nó ít nhiều gần hoặc đạt đến phiên bản cuối cùng. Bằng cách này, các nhà phát triển khách hàng sẽ thấy các đề xuất cải tiến Ethereum trưởng thành, ít nhất có thể là một triển khai ban đầu và hầu hết các câu hỏi mở có liên quan đã được trả lời.

Ngoài ra, retesth, một công cụ kiểm tra mới do nhóm kiểm tra EF phát triển, sẽ cho phép nhóm làm việc tạo các kiểm tra tham chiếu EIP cần thiết cho bất kỳ khách hàng nào (hiện tại là Geth, Aleth và Hyperledger Besu). Do đó, khuôn khổ nhóm làm việc này sẽ không chỉ phi tập trung hóa quy trình sàng lọc các đề xuất cải tiến Ethereum mà còn giảm áp lực và tắc nghẽn thử nghiệm.

Bênh vực eEIP

Trong quá trình chuẩn bị cho việc nâng cấp Istanbul, không có gì lạ khi tất cả các nhà phát triển cốt lõi có các cuộc gọi hội nghị mà không ai nói về các đề xuất cải tiến Ethereum cụ thể. Sự phụ thuộc lẫn nhau hoặc các đề xuất cạnh tranh có thể làm chậm đáng kể tiến độ của toàn bộ quá trình nâng cấp.

Mô tả hình ảnh

-Cảm ơn MP và Boris đã hỗ trợ tổ chức một hội thảo để thảo luận về những vấn đề này-

Vai trò của người hỗ trợ là biến họ thành đầu mối liên hệ cho EIP. Họ không chịu trách nhiệm cho tất cả công việc và không nhất thiết phải tự thực hiện, nhưng họ phải là nhân vật chủ chốt trong việc thực hiện các đề xuất cải tiến Ethereum và cam kết truyền đạt đầy đủ quá trình nâng cấp với các thành viên trong cộng đồng.

tiêu đề phụ

ngã ba lấy EIP làm trung tâm

Một ý tưởng khác, được đề xuất gần đây bởi Martin Holst Swende của nhóm EF, là điều chỉnh quy trình nâng cấp mạng Ethereum để tập trung vào EIP hơn. Thay vì tập trung vào việc nâng cấp và cố gắng đảm bảo rằng tất cả các đề xuất cải tiến Ethereum đều ở trong từng giai đoạn nâng cấp, tốt hơn là nên tập trung vào việc làm cho mỗi EIP hoàn thiện và chỉ lên kế hoạch nâng cấp cho các EIP trưởng thành, đáng tin cậy.

Nếu bất kỳ ai muốn đưa Đề xuất cải tiến Ethereum từ giai đoạn dự thảo sang kích hoạt mạng chính thành công, thì đây là cách họ thực hiện trong khuôn khổ này (trích dẫn từ đề xuất ban đầu, với một số chỉnh sửa nhỏ để dễ đọc):

Bước 1: Nhận xác nhận từ ACD

Giả sử rằng Đề xuất cải tiến Ethereum tồn tại (bước 0), ALCORIEDEV (diễn đàn) ban đầu sẽ quyết định xem Đề xuất cải tiến Ethereum có được "chấp nhận sơ bộ" hay không. "Chấp nhận sơ bộ" (hoặc "tích cực") có nghĩa là các khách hàng lớn và các bên liên quan trong hệ sinh thái có thái độ tích cực đối với đề xuất cải tiến Ethereum, sẵn sàng chấp nhận PR (được viết tốt) để tích hợp EIP vào cơ sở mã và Bắt đầu thử nghiệm.. .nhưng giai đoạn này sẽ không chỉ định chiều cao khối thực tế của việc kích hoạt.

Trạng thái "chấp nhận sơ bộ" này cũng là một cơ chế báo hiệu hữu ích cho các tổ chức tài trợ cho việc nâng cấp giao thức như EF, ConsenSys hoặc thậm chí là MolochDAO. Việc tài trợ có thể được chia thành nhiều giai đoạn (nghĩa là trước và sau khi "chấp nhận ban đầu") để đảm bảo rằng phần lớn số tiền được chi cho các sáng kiến ​​tạo điều kiện khởi chạy mạng chính.

Bước 2: Thực hiện

Khi ACD đã đưa ra một định hướng rõ ràng, các nhà phát triển và các tác giả đề xuất cải tiến Ethereum khác có thể bắt tay vào triển khai nó và phát hành các bản cập nhật cho khách hàng.

Cột mốc này hoàn tất nếu chức năng đã triển khai được hợp nhất vào máy khách chính.

Bước 3: Trường hợp thử nghiệm

Vì tính năng này hiện có thể được "kích hoạt" trong ứng dụng khách, nên giờ đây có thể tạo các thử nghiệm máy khách chéo cho tính năng này, các trường hợp thử nghiệm phải chứa các thử nghiệm đường dẫn hạnh phúc và thử nghiệm quirk/edgecase, bước này không chỉ dành cho những Người chuyên sâu hiểu và nắm rõ về EVM (Ethereum Virtual Machine) sẽ cùng nhau thực hiện nhằm hạn chế tối đa khả năng sai sót.

Ở giai đoạn này, cũng nên tiến hành đánh giá bảo mật và dự án đánh giá phải được phản hồi lại đề xuất cải tiến Ethereum dưới danh nghĩa "cân nhắc bảo mật". dễ dàng bỏ qua. Việc hoàn thành giai đoạn này được đánh dấu bằng sự chấp thuận của nhóm thử nghiệm.

Bước 4: Nghiệm thu cuối cùng của ACD

“Vì vậy, hãy kích hoạt Đề xuất cải tiến Ethereum này (ở độ cao khối X) trên mạng thử nghiệm một tháng sau đó và kích hoạt Đề xuất cải tiến Ethereum này trên mạng chính (ở độ cao khối Y) hai tháng sau.” Tất cả khách hàng sẽ bao gồm bản nâng cấp trong bản phát hành tiếp theo và cũng có thể trì hoãn các đề xuất cải tiến Ethereum thông qua cờ dòng lệnh trong một tuần kể từ bây giờ.

Nếu nhiều Đề xuất cải tiến Ethereum đạt đến bước 4 cùng một lúc, ACD có thể quyết định khởi chạy hai hoặc ba Đề xuất cải tiến Ethereum cùng một lúc, trừ khi có lo ngại rằng Đề xuất cải tiến Ethereum có thể có các phụ thuộc/khớp nối nội bộ (có thể dẫn đến nhiễu thử nghiệm không cần thiết).

Mô tả hình ảnh

-Cảm ơn James Hancock đã vẽ một bức tranh rõ nét như vậy! -

Việc sử dụng khuôn khổ này sẽ cho phép mỗi đề xuất cải tiến Ethereum di chuyển theo tốc độ của riêng nó, do đó giảm thời gian và phạm vi tranh luận trong quá trình nâng cấp, đồng thời giảm áp lực cho nhóm thử nghiệm vì quá trình này dễ dự đoán hơn trước. Không phải tranh giành để tập trung vào thử nghiệm trước thời hạn.

tiêu đề phụ

• Đề xuất cải tiến Ethereum 1872

• Một đề xuất khác để làm trơn tru quá trình nâng cấp của mạng Ethereum là Đề xuất 1872, được đề xuất bởi Danno Ferrin. Khi ngày càng có nhiều công ty dựa vào Ethereum như một phần cốt lõi trong cơ sở hạ tầng của họ, chúng ta nên nỗ lực để nâng cấp mạng dễ dự đoán hơn.

• Đề xuất đề xuất rằng ethereum áp dụng lịch trình mặc định để nâng cấp mạng, tương tự như bản phát hành bản vá lỗi thông thường vào Thứ Ba của Microsoft. Bằng cách đó, những người chạy các nút ethereum biết khi nào họ có khả năng cao sẽ theo dõi các bản nâng cấp tiềm năng. Nói tóm lại, đề xuất này gợi ý rằng chúng tôi làm điều này:

• Thực hiện nâng cấp mainnet theo mặc định vào thứ Tư của tuần thứ ba trong tháng, tốt nhất là vào tháng 1, tháng 4, tháng 7 hoặc tháng 10 để tránh hầu hết các ngày lễ lớn của Hoa Kỳ và Châu Âu.

Nếu quá trình nâng cấp không triển khai như dự kiến, thì quá trình này sẽ bị hoãn lại cho đến Thứ Tư của tuần thứ ba của tháng tiếp theo (như đã xảy ra trong quá trình nâng cấp Constantinople)

Bất cứ khi nào và bất cứ nơi nào một vấn đề xảy ra, giải quyết nó ngay lập tức

EIP này sẽ không hạn chế khả năng đối phó với các tình huống bất ngờ của chúng tôi mà chỉ nhấn mạnh tính định kỳ mặc định, chẳng hạn như nâng cấp cố định 6 tháng một lần, để giảm bớt lo ngại của thị trường về sự không chắc chắn của việc nâng cấp, đồng thời giảm thời gian liên lạc của các nhà phát triển cốt lõi trong quá trình nâng cấp. quá trình.

Nó cũng cung cấp một "nền tảng trung gian" giữa cách tiếp cận hiện tại của chúng tôi và cách tiếp cận "một Đề xuất cải tiến Ethereum, một lần nâng cấp" (tức là cách tiếp cận fork lấy EIP làm trung tâm).

tiêu đề phụ

mô hình nhà ga

Kết hợp các phần của các đề xuất trên, chúng tôi đã đạt được một quy trình gần với cách thức hoạt động của các nhà ga xe lửa hơn là quy trình "gần giống với cách thức hoạt động của các sân bay" hiện tại của chúng tôi.

Hiện tại, các nâng cấp của chúng tôi tương tự như cách thức hoạt động của việc mua vé máy bay: ngày giờ cố định và chúng tôi cố gắng đưa mọi người lên máy bay bất kể điều gì xảy ra, ngay cả khi có sự chậm trễ bằng cách kiểm tra hành lý của họ.

Chúng tôi tin rằng việc chuyển sang mô hình nơi mọi người xuất hiện tại ga tàu với hành lý trên tay, sẵn sàng lên đường và lên chuyến tàu có sẵn tiếp theo sẽ giúp quá trình nâng cấp mạng diễn ra suôn sẻ hơn nhiều so với hiện tại.

Cụ thể, mô hình ga tàu chủ yếu có bốn phần.

Đầu tiên, mỗi đề xuất cải tiến Ethereum nên tiến hành độc lập. Các nhóm làm việc có thể đẩy các đề xuất về phía trước và chỉ khi Đề xuất cải tiến Ethereum ở trạng thái sẵn sàng hoạt động, chúng tôi mới lên lịch nâng cấp mạng cho đề xuất đó.

Thứ hai, các đề xuất cải tiến Ethereum và các nhóm làm việc cần những nhà vô địch. Những nhà vô địch này sẽ đóng vai trò là đại diện và điểm liên hệ mặc định cho các đề xuất cải tiến Ethereum. Họ chịu trách nhiệm truyền đạt đề xuất tới cộng đồng trên AllCoreDevs hoặc các diễn đàn khác và họ có thể hoặc không phải là người triển khai thực tế của EIP.

Thứ ba, công bố những gì được thực hiện. Khi mạng sắp được nâng cấp, hãy đưa tất cả các EIP đã sẵn sàng phát hành vào bản nâng cấp. Sẽ không có sự leo thang nào đối với bất kỳ đề xuất nào vẫn đang được thảo luận. Tương tự, nếu một đề xuất gặp vấn đề vào phút cuối, chúng tôi sẽ chuyển đề xuất đó sang lần nâng cấp tiếp theo thay vì hoãn toàn bộ việc nâng cấp.