Ý tưởng cải tiến quy trình EIP: vay mượn từ quy trình RFC và W3C

以太坊爱好者

特邀专栏作者

2020-09-21 13:46 (UTC+8)

Bài viết này có khoảng 3728 từ, đọc toàn bộ bài viết mất khoảng 6 phút

Chủ yếu lấy cảm hứng từ các quy trình RFC và W3C.

Tóm tắt AI

Chủ yếu lấy cảm hứng từ các quy trình RFC và W3C.

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ừ

Những người đam mê Ethereum (ID: ethfans)

, Tác giả: Alex Beregszaszi, bản dịch & hiệu đính: Min Min & A Jian, được Odaily tái bản với sự cho phép.

Tóm tắt một câu: Đầu tiên, tôi sẽ giới thiệu chung về quy trình EIP và những điều chỉnh của nó trong năm 2019. Sau đó, tôi sẽ đề xuất một quy trình EIP mới, phần lớn lấy cảm hứng từ các quy trình RFC và W3C.

Kể từ năm 2016, tôi đã tham gia vào EIP (Đề xuất cải tiến Ethereum). Tôi bắt đầu với tư cách là một cộng tác viên, sau đó tham gia vào "quy trình AllCoreDev" và đảm nhận các nhiệm vụ biên tập.
quá trình hiện tại

Có hai quy trình riêng biệt trong thư viện EIP hiện tại:

Sự chỉ rõ

Triển khai toàn bộ mạng (kế hoạch hard fork)
EIP-1 và EIP 233 xác định các phần của cả hai quy trình. Sau đó, EIP-2378 đã mở rộng trên cơ sở này.
Vào năm 2019, một số thay đổi đã được đề xuất, 4 trong số đó có liên quan đến tình trạng của đề xuất:
Giới thiệu trạng thái "Đánh giá"

Đổi tên "Được chấp nhận" thành "Sẵn sàng"

Giới thiệu trạng thái "Bị bỏ rơi"

Xóa trạng thái "Trì hoãn"

Động lực để giới thiệu hai thay đổi đầu tiên là tương tự, nhưng hơi khác một chút. Trạng thái "Đánh giá" là một giai đoạn mới trong đó các đề xuất không được thực hiện khẩn cấp, mặc dù có những đề xuất rõ ràng để xem xét rộng rãi hơn. Trạng thái "Sẵn sàng" chỉ là một thay đổi gia tăng nhỏ và âm thanh nhẹ nhàng hơn "Đã chấp nhận", nhưng quá trình hard fork trong EIP-1 vẫn được giữ lại.

Trạng thái "Bị bỏ rơi" được giới thiệu để xóa nhiều bản nháp bị bỏ rơi. Rõ ràng, trạng thái "Rút tiền" không được sử dụng trước đó đã bị xóa.

Do những thay đổi trong EIP-233 và EIP-2378, trạng thái "Hoãn lại" đã trở nên lỗi thời và đã bị xóa.

Ngoài ra còn có các đề xuất để loại bỏ các trạng thái hard fork khác như "Được chấp nhận" và "Bị từ chối".

Lưu ý rằng tôi sẽ không giải thích chi tiết ý nghĩa của từng trạng thái trong sơ đồ bên dưới. Vui lòng đọc EIP-1 cho từng trường hợp góc. Tuy nhiên, 'Quy trình đề xuất' dưới đây cung cấp một lời giải thích hợp lý. "

Vào tháng 6 năm 2019, chúng tôi đã thảo luận sâu về sự phức tạp của quy trình EIP. Nếu từng trạng thái được xem xét, thì toàn bộ luồng EIP (trước khi trạng thái "Hoãn lại" bị xóa) được hiển thị trong sơ đồ sau:

Vào thời điểm đó, tôi cho rằng EIP có thể thay đổi từ trạng thái "Cuộc gọi cuối cùng (lần cuối để nhận xét)" sang trạng thái "Đã bỏ qua", mặc dù nó không được ghi trong tài liệu.

Điều tôi chưa đề cập là có hai EIP với các quy trình khác nhau và không phải tất cả các kết hợp ở trên đều hợp lệ.

Quy trình của EIP "cốt lõi" như sau:

Cần lưu ý ở đây rằng EIP "cốt lõi" đã không giới thiệu trạng thái "Cuộc gọi cuối cùng" cho đến gần đây.

Quy trình cho EIP "không cốt lõi" như sau:

Vào tháng 5 năm 2020, tôi đã đề xuất một quy trình đơn giản hơn:

Chúng tôi đã thảo luận về điểm này. Nhưng giống như nhiều đề xuất đang trải qua quá trình EIP, đề xuất này đã không tiến triển.

ngã ba cứng

Cũng gây tranh cãi là liệu có nên hợp nhất hai trạng thái "Đã rút lui" và "Bị bỏ rơi" hay không. Điều này đã được giải thích rõ ràng trong các vấn đề gần đây.

Trong cuộc điện đàm, cũng có ý kiến đề nghị nên dùng từ “Sống” thay cho từ “Hoạt động”. Cái trước có thể không phải là lựa chọn tốt nhất, nhưng nó nghe hay hơn cái sau.

ngã ba cứng

Tôi ủng hộ việc tách biệt hai quy trình quản lý hard fork và quản lý canonical. Bây giờ có vẻ như nhiều người nghĩ như vậy. Điều này làm cho quá trình dễ dàng hơn và mượt mà hơn.

Theo tin tức mới từ cuộc họp toàn bộ các nhà phát triển cốt lõi, hiện tại dường như có một kho lưu trữ thông số kỹ thuật ETH 1.0 dành riêng cho việc theo dõi và quản lý các đề xuất cũng như thử nghiệm chúng trên cái gọi là mạng thử nghiệm tạm thời "YOLO".

Tôi nghĩ rằng ngay cả khi quy trình hard fork cuối cùng còn lại bị xóa khỏi thư viện EIP, thì ý tưởng ban đầu của EIP-233 vẫn hợp lý: ghi lại quá trình hard fork hiện có trong tài liệu meta (đặt nó vào cùng một tệp với EIP mô tả sự thay đổi đặc điểm kỹ thuật. cùng nhau)

Tuy nhiên, mọi người đã tiến thêm một bước so với ý tưởng ban đầu về EIP-233 và quy tắc là tạo một tài liệu meta càng sớm càng tốt để làm rõ tên của hard fork, bởi vì các máy khách khác nhau sử dụng các tên khác nhau. Nhưng sau khi cơ chế đặt tên được thống nhất, vấn đề này không còn là vấn đề nữa.

Cuối cùng, ý tưởng về EIP-233 lại được mở rộng, kéo dài quá trình theo dõi các hard fork trong quá trình lập kế hoạch và điều phối. May mắn thay, trong tương lai, điều này sẽ được xử lý bởi thông số kỹ thuật của ETH 1.0.

Sau khi hard fork xảy ra, tất cả dữ liệu được ghi lại trong "hard fork metas". Các metas hard ford đã được chứng minh là một nguồn tài nguyên rất hữu ích.

quá trình đề xuất của tôi

Để đứng trên vai những người khổng lồ, nguồn tài nguyên tốt nhất mà chúng tôi đã tìm thấy là quy trình RFC và quy trình W3C. Mặc dù các thông số kỹ thuật liên quan đến hai quy trình này thường lớn hơn nhiều so với EIP, nhưng tôi nghĩ chúng ta có thể học hỏi từ chúng.

Ở đây, tôi đang mượn một số thuật ngữ yêu thích của cá nhân tôi từ quy trình W3C. Tuy nhiên, có các tùy chọn khác được đưa ra trong hình trên, cả các điều khoản hiện có hoặc các điều khoản được đề xuất. Cá nhân tôi thích thuật ngữ "Ứng viên" hơn.

Ý tưởng

Trước khi bất kỳ đề xuất nào được gửi, cần có một giai đoạn cân nhắc trước khi gửi yêu cầu kéo (pull request) tạo bản nháp. Chúng ta có thể thảo luận và phê bình các ý tưởng trên Ethereum Magicians, ethresear.ch và các kênh trên Gitter hoặc Discord.

Bản nháp

Giả sử rằng một ý tưởng thu hút được sự quan tâm, chúng ta nên tạo bản nháp cho ý tưởng đó dựa trên mẫu EIP. Miễn là bản thảo này đáp ứng các yêu cầu cơ bản về ngữ pháp, chúng ta nên hợp nhất nó.

Câu hỏi: Các ý kiến khác nhau về mức độ thẩm quyền mà các biên tập viên nên có để xem xét các đề xuất và không có câu trả lời rõ ràng. Nếu chúng tôi có một quy trình tốt để xóa các EIP không thành công, thì việc hợp nhất các bản nháp sớm hơn chắc chắn là điều nên làm.

Ở giai đoạn này, dự thảo dự kiến sẽ được thảo luận bởi một nhóm nhỏ những người tham gia quan tâm.

Không có giới hạn thời gian cho trạng thái "Bản nháp", nhưng không nên vượt quá khung thời gian hợp lý (vài tháng).

Ứng viên (ứng viên)/Đánh giá (đánh giá)

Giai đoạn này nên được thực hiện sau khi dự thảo đủ ổn định để không cần phải sửa đổi lớn nữa.

Ở giai đoạn này, nhiều người tham gia cung cấp phản hồi hơn. Tại thời điểm này, những người tham gia có lý do để tin rằng thông số kỹ thuật sẽ không đột ngột thay đổi đáng kể, vì vậy họ có nhiều khả năng đầu tư thời gian vào việc xem xét và thảo luận về nó.

Giai đoạn này nên kéo dài ít nhất 45 ngày để cho phép thu thập phản hồi.

Proposed (được đề xuất)/Last Call (cuộc gọi cuối để lấy ý kiến)

Giai đoạn này nên được bắt đầu khi những người tham gia cảm thấy rằng thông số kỹ thuật đủ ổn định để không thực hiện thêm thay đổi nào nữa.

Ở giai đoạn này, thông số kỹ thuật sẽ được đẩy tới nhiều người tham gia hơn để lấy ý kiến. Sau đó, thông số kỹ thuật được hoàn thiện và không thể thay đổi. [ngoại trừ "errata (kan)", xem bên dưới để biết chi tiết]

Giai đoạn này sẽ kéo dài ít nhất 14 ngày.

Nếu cần điều chỉnh nhỏ, nó có thể được thực hiện mà không thay đổi trạng thái hiện tại, nếu không, nó phải quay trở lại trạng thái "Ứng cử viên".

Yêu cầu đặc biệt: Trường ngày kết thúc đánh giá phải được bao gồm trong vấn đề chính.

Cuối cùng

Nếu thông số kỹ thuật ở trạng thái "Được đề xuất" được thông qua thành công, thì thông số kỹ thuật đó sẽ được hoàn thiện.

rút tiền
Ngoại trừ "Final" và "Living", tất cả các trạng thái khác có thể trở thành trạng thái này.

Yêu cầu đặc biệt: Các tình huống sau có thể dẫn đến trạng thái "Đã rút tiền" nhưng phải có trường lý do:

rút lại bởi tác giả: Tác giả đã đưa ra quyết định rút tiền ở bất kỳ giai đoạn nào

rút lại do không hoạt động: Tác giả đã không có hoạt động nào trong một khoảng thời gian xác định (180 ngày).

Sống/Hoạt động

Những EIP-1 dưới dạng sổ đăng ký và các EIP đặc biệt khác sẽ được đánh dấu bằng trạng thái này, vì chúng sẽ không bao giờ được hoàn thiện.

Bất kỳ tài liệu đăng ký mới nào cũng phải trải qua quy trình EIP đầy đủ trước khi trở thành trạng thái "Đang hoạt động".

lưu trữ

Mặc dù đây không phải là trạng thái, nhưng theo cách này, các EIP đã bị thu hồi trong một thời gian dài có thể được xóa để tránh làm đầy thư viện EIP. Nhấn vào đây để biết thêm chi tiết.
lỗi thời

Đây không phải là một trạng thái, mà là một quá trình loại bỏ từng bước vay mượn từ RFC. Quá trình này giới thiệu hai lĩnh vực:

lỗi thời: Chứa số EIP lỗi thời EIP hiện tại

lỗi thời: Chứa một tập hợp các số EIP đã lỗi thời bởi EIP hiện tại

EIP hiện tại chỉ có thể sử dụng trường lỗi thời khi nó ở trạng thái Cuối cùng hoặc Đã rút tiền.

EIP hiện tại chỉ có thể có trường lỗi thời nếu trường "lỗi thời" của EIP được tham chiếu trỏ tới EIP hiện tại.

Điều này có nghĩa là các tác giả của EIP với tư cách là bên bị loại bỏ và bên bị loại bỏ phải đạt được sự đồng thuận. Điều này có thể thay đổi trong tương lai với đề xuất về một quy trình loại bỏ tốt hơn.

Remark

Sai lầm (errata)

Các lỗi đánh máy nhỏ có thể được sửa bởi người biên tập, theo quy ước.
Có thể cho rằng, bất kỳ sửa đổi nào giúp làm rõ đặc điểm kỹ thuật đều được chấp nhận miễn là nó không thay đổi đề xuất ban đầu ngoài khả năng nhận dạng, vì các sửa đổi nhỏ có thể được giải thích trong phần Errata. Nếu cần phải sửa đổi lớn, EIP tương ứng phải được gỡ bỏ và phải tạo một EIP mới.
resolution

Các trường quan trọng sau đã bị xóa vì chúng không được chỉ định và/hoặc không được sử dụng:

thay thế (được thay thế bằng quá trình loại bỏ)