Tiêu đề gốc: "Bản cập nhật cuộc họp dành cho nhà phát triển Ethereum Core 014"
Nguồn gốc: Cập nhật AllCoreDevs
Tác giả gốc: Tim Beiko
Bản tổng hợp gốc: Ethereum.cn
Chào mừng bạn đến với phiên bản cập nhật mới của AllCoreDevs (Hội nghị nhà phát triển Ethereum Core) – phiên bản cuối cùng của năm 2022.
Tổng quan
Nội dung nâng cấp Shanghai/Capella đã được hoàn thiện: rút tiền, EOF và một số sửa đổi nhỏ... miễn là chúng không trì hoãn việc rút tiền.
Không gian Blob sắp ra mắt: EIP-4844 sẽ là trung tâm của bản nâng cấp tiếp theo của Ethereum và lễ triệu tập của nó sẽ sớm bắt đầu.
Về mặt kỹ thuật, các nỗ lực đang được tiến hành để phối hợp các quy trình nâng cấp của lớp thực thi và lớp đồng thuận. Chúng tôi cũng đang thấy các cuộc thảo luận tích cực về việc kết hợp tốt hơn ý kiến đóng góp của cộng đồng vào quy trình.
Protocol Guild đã công bố một báo cáo thí điểm giữa kỳ và một kế hoạch sơ bộ nhằm mở rộng quy mô của những nhà bảo trì cấp một và hỗ trợ họ tốt hơn vào năm 2023.
Nâng cấp Thượng Hải/Capella
Tại AllCoreDevs gần đây, nhóm khách hàng đã đạt được sự đồng thuận về phạm vi cuối cùng của bản nâng cấp Shanghai/Capella. Mặc dù tên của bản nâng cấp có thể còn gây tranh cãi nhưng nhóm đã rõ ràng về phạm vi của nó. Tính năng chính của bản nâng cấp là giới thiệu tính năng rút tiền Beacon Chain cho người đặt cọc. Triển khai tính năng này càng nhanh càng tốt là điều mà nhóm khách hàng không muốn thỏa hiệp, vì vậy, các tính năng khác trong bản nâng cấp cần phải sẵn sàng cùng lúc, nếu không sẽ có nguy cơ bị bỏ rơi.
Đặc tả lớp điều hành Thượng Hải liệt kê tất cả các EIP được bao gồm:
EIP-3540: Định dạng đối tượng EVM (EOF) v1
EIP-3651: Giảm chi phí gas khi truy cập địa chỉ COINBASE
EIP-3670: EOF - Xác minh mã
EIP-3855: Đã thêm mã opcode PUSH 0
EIP-3860: Giới hạn kích thước initcode và giới thiệu tính năng đo khí
EIP-4200: EOF - bước nhảy tương đối tĩnh
EIP-4750: EOF - Chức năng nhập
EIP-4895: Rút tiền đẩy chuỗi Beacon khi vận hành hệ thống
EIP-5450: EOF - Xác minh ngăn xếp
Mặc dù danh sách dài nhưng nó có thể được chia thành ba phần khác nhau: cải tiến nhỏ, định dạng đối tượng EVM và rút tiền. Tiếp theo chúng tôi sẽ giới thiệu từng người một:
Cải tiến nhỏ
EIP-3651: COINBASE ấm áp (giảm chi phí gas khi truy cập địa chỉ COINBASE)
EIP này khắc phục lỗi giám sát trong EIP-2929 trong đó chi phí gas khi truy cập một số trường dữ liệu nhất định đã được sửa đổi dựa trên việc dữ liệu đã có trong bộ nhớ máy khách (WARM) hay cần được lấy từ đĩa (COLD).
EIP-2929 đặt hai phần dữ liệu trong bộ nhớ máy khách thành WARM khi bắt đầu mỗi giao dịch: địa chỉ gửi và địa chỉ nhận. EIP-3651 thêm địa chỉ thứ ba vào danh sách này, địa chỉ COINBASE (tức là FeeRecipient), vì đó cũng là địa chỉ mà khách hàng có trong bộ nhớ khi xử lý các giao dịch khối.
EIP-3855: Lệnh PUSH 0 (mã hoạt động mới `PUSH 0)
Đúng như tên gọi, EIP-3855 giới thiệu một opcode đẩy giá trị 0 vào ngăn xếp. Việc đẩy số 0 thường được sử dụng để điền các giá trị trong EVM, opcode này sẽ cung cấp cách hiệu quả hơn và rẻ hơn để thực hiện việc này.
EIP-3860: Giới hạn và đo initcode (giới hạn kích thước của initcode và giới thiệu đo khí)
EIP này bổ sung giới hạn về kích thước của initcode và giới thiệu tính năng đo khí dựa trên độ dài của nó. Giới hạn kích thước trên của nó bổ sung thêm một bất biến cho EVM, giúp dễ hiểu và đề xuất sửa đổi hơn.
Giới thiệu chi phí chung là 2 gas trên 32 byte cho initcode, được sử dụng để thanh toán cho phân tích nhảy nhanh nhất mà khách hàng phải thực hiện trước khi thực hiện, phân tích này không được liệt kê trong đồng hồ đo gas.
định dạng đối tượng
Hầu hết EIP có trong bản nâng cấp Thượng Hải thực sự là một phần của một tính năng duy nhất: Định dạng đối tượng EVM (EOF). Công việc được chia thành 5 EIP khác nhau để giúp các nhà phát triển khách hàng hiểu từng sửa đổi riêng lẻ, nhưng để cung cấp cái nhìn tổng quan ở cấp độ cao hơn, các nhà phát triển đã đưa ra một thông số kỹ thuật thống nhất. EIP của năm EOF này là:
EIP-3540: Định dạng đối tượng EVM phiên bản 1
EIP-3670: EOF - Xác minh mã
EIP-4200: EOF - bước nhảy tương đối tĩnh
EIP-4750: EOF - Chức năng nhập
EIP-5450: EOF - Xác minh ngăn xếp
Điều đáng chú ý là bước đầu tiên của EOF là bản nâng cấp EIP-3541 của London, dành riêng tiền tố 0xEF 00 cho hợp đồng EOF. Phạm vi EOF của bản nâng cấp Thượng Hải cũng đã thay đổi trong vài tháng qua.
Vào tháng 2, nhóm khách hàng đã đồng ý xem xét nâng cấp ở Thượng Hải để bao gồm hai EOF EIP nhỏ nhất: EIP 3540 & 3670. Tất cả chúng sẽ đóng vai trò là các khối xây dựng nhưng sẽ không cung cấp đầy đủ chức năng nếu không có EIP 4200, 4750 và 5450. Mặc dù có thể mở rộng EOF nhưng tính không tương thích ngược có thể yêu cầu phiên bản mới. Vì các hợp đồng tiền EOF hoặc EOF với một phiên bản cụ thể phải luôn có thể thực thi được nên mỗi phiên bản EOF mới có nghĩa là các nhà phát triển ứng dụng khách phải duy trì một bộ quy tắc thực thi EVM mới song song với các quy tắc cũ.
Trước EOF, mỗi lần khách hàng chỉ duy trì một bộ quy tắc EVM. Cơ sở mã cũng hỗ trợ các quy tắc EVM trước đó, được sửa đổi với mỗi lần nâng cấp mạng, nhưng khi chúng đạt đến phần đầu của chuỗi khối, chỉ những quy tắc mới nhất phải được áp dụng. Sau khi triển khai EOF, khách hàng sẽ duy trì hai bộ quy tắc EVM song song để họ có thể thực thi mã trong hợp đồng EOF và không phải EOF. Nói cách khác, việc tăng các phiên bản EOF sẽ làm tăng số lượng bộ quy tắc EVM song song thay vì liên tiếp phải được duy trì.
Để đạt được mục tiêu này, trong vài tháng qua, các nhóm khách hàng đã bắt đầu ưa chuộng cách tiếp cận "EOF lớn". Bằng cách này, mặc dù họ phải triển khai các bộ sửa đổi lớn hơn nhưng phiên bản EOF sẽ tồn tại lâu hơn và giảm số lượng "EVM song song" cần được duy trì. Do đó, các nhà phát triển đã cân nhắc "EOF lớn" và cuối cùng đưa nó vào bản nâng cấp Thượng Hải.
Điều đó nói lên rằng, các tính năng lớn hơn rõ ràng là khó triển khai và thử nghiệm hơn và nhóm không muốn thấy việc rút tiền khỏi chuỗi beacon của EOF bị trì hoãn nghiêm trọng. Do đó, nếu việc triển khai EOF chưa được hoàn thành trước tháng 1 và chúng không thể tương tác nhanh chóng với nhau thì nhóm khách hàng đồng ý chuyển EOF ra khỏi Thượng Hải để nâng cấp.
Với những bối cảnh này, bây giờ chúng ta hãy giới thiệu ngắn gọn từng EOF EIP:
EIP-3540: Định dạng đối tượng EVM (EOF) v1 (Định dạng đối tượng EVM phiên bản 1)
EIP này giới thiệu "container" cho hợp đồng EOF. Nó thêm các thẻ để phân biệt các phần mã và dữ liệu của hợp đồng và ngăn các hợp đồng EOF không tuân thủ định dạng được triển khai. Điều này đảm bảo rằng mọi hợp đồng EOF trên chuỗi sẽ tuân theo định dạng hợp lệ, giúp đơn giản hóa việc tương tác với các hợp đồng này, cũng như phân tích tĩnh về chúng.
EIP-3670: EOF - Xác thực mã (EOF - Xác thực mã)
Dựa trên container được giới thiệu bởi 3540, EIP-3670 đảm bảo rằng mã trong hợp đồng EOF là hợp lệ hoặc ngăn không cho nó được triển khai.
Điều này có nghĩa là các opcode không xác định không thể được triển khai trong hợp đồng EOF, điều này có thêm lợi ích là giảm số lượng phiên bản EOF cần thêm vào. Nếu một opcode mới được thêm vào, các quy tắc xác thực có thể được thay đổi một cách đơn giản để kích hoạt nó và đảm bảo rằng không có hợp đồng EOF nào được triển khai tham chiếu nó trong phần mã của nó.
EIP-4200: EOF - Bước nhảy tương đối tĩnh (EOF - Bước nhảy tương đối tĩnh)
EIP-4200 giới thiệu các mã hoạt động dành riêng cho EOF đầu tiên: RJUMP, RJUMPI và RJUMPV, mã hóa đích dưới dạng giá trị tức thời đã ký. Các mã opcode JUMP mới này có thể được các trình biên dịch sử dụng để tối ưu hóa chi phí gas vì chúng loại bỏ nhu cầu phân tích điểm nhảy thời gian chạy, vốn được yêu cầu bởi các mã opcode JUMP & JUMPI hiện có.
EIP-4750: EOF - Chức năng (các chức năng do EOF giới thiệu)
EIP-4750 tiến một bước xa hơn 4200: nó không cho phép sử dụng mã hoạt động JUMP & JUMPI và thêm các lựa chọn thay thế cho các chức năng không thể sao chép. Nó được triển khai bằng cách giới thiệu các phần chức năng cụ thể trong mã byte EOF. Các hàm này có thể chuyển từ các mã hoạt động JUMPF, CALLF và RETF mới tương ứng và sử dụng chúng để gọi và trả về.
EIP-5450: EOF - Xác thực ngăn xếp (Xác thực ngăn xếp EOF)
Cuối cùng, EIP-5450 bổ sung thêm một bước kiểm tra xác thực khác cho các hợp đồng EOF, lần này là xung quanh ngăn xếp. EIP này ngăn các hợp đồng EOF triển khai mã có thể gây ra tình trạng tràn ngăn xếp và tràn trong một số trường hợp. Với EIP này, khách hàng có thể giảm số lần kiểm tra xác thực khi thực hiện hợp đồng EOF vì họ có sự đảm bảo tốt hơn về các ngoại lệ liên quan đến ngăn xếp.
Là một chuyên gia không phải EVM nhưng lại rất tập trung vào EIP, tôi không thể nói nhiều về nó! Nếu độc giả muốn tìm hiểu thêm về EOF, tôi khuyên bạn nên sử dụng các tweet có liên quan được đăng bởi các khách hàng ánh sáng từ nhóm Geth và Leo từ nhóm Solidity.
Rút chuỗi Beacon
Cuối cùng nhưng không kém phần quan trọng, phần chính của "Shapella" (Ghi chú của người dịch: tên chung của Shanghai/Capella) là việc rút chuỗi đèn hiệu. Phần thay đổi này được mô tả trong đặc tả lớp đồng thuận và EIP-4895. Hiện tại có một đặc tả meta hơi lỗi thời liên kết những thay đổi này lại với nhau.
Ở cấp độ cao, cơ chế rút tiền như sau:
Khi đề xuất một khối, trình xác thực sẽ quét tuyến tính chỉ mục của trình xác thực để tìm 16 trình xác thực đầu tiên có thông tin xác thực 0x01, cần đáp ứng một trong các điều kiện sau:
Có số dư trên 32 ETH (tức là đã tích lũy phần thưởng xác thực)
Có thể rút được (tức là đã thoát hoàn toàn bộ trình xác thực)
Số dư lớn hơn 32 ETH (tức là đã nhận được phần thưởng xác thực)
Nó có thể rút được (có thể rút được, nghĩa là nó đã thoát hoàn toàn khỏi bộ xác thực)
Từ đó, người xác thực sẽ tạo danh sách các khoản rút tiền để đưa vào ExecutionPayload của họ. Mỗi mục trong danh sách đó chứa những mục sau:
Trình xác thực sẽ tạo danh sách rút tiền từ các trình xác thực này và đóng gói nó vào ExecutionPayload của họ. Mỗi mục trong danh sách chứa các mục sau:
WithdrawalIndex: Chỉ số của tất cả các giao dịch rút tiền đã được thực hiện - điều này giúp phân biệt các lần rút tiền cùng số tiền từ cùng một địa chỉ, cùng một trình xác nhận
ValidatorIndex: chỉ mục xác thực nơi số dư được tăng lên
ExecutionAddress: Địa chỉ ETH của lớp thực thi, nơi số tiền rút sẽ được gửi đến
Số tiền: Số tiền được gửi đến ExecutionAddress, số tiền này được đo bằng gwei (không phải wei)
Các máy khách lớp thực thi sẽ thực hiện việc rút tiền này sau khi các giao dịch được thực hiện khi xây dựng hoặc xử lý các khối. Nói cách khác, việc rút tiền được xử lý theo cách tương tự như phần thưởng bằng chứng công việc được ghi lại và nó không cạnh tranh với các giao dịch của người dùng về không gian khối.
Có một số chi tiết khác đáng chú ý:
Khi xử lý việc rút tiền, không có sự khác biệt về mức độ ưu tiên/thứ tự giữa "tiền đầy đủ" và "tiền một phần". Việc rút toàn bộ xảy ra khi người xác thực rời khỏi nhóm thoát, trong khi việc rút tiền một phần xảy ra định kỳ, nghĩa là khi thực hiện quét tuyến tính bộ trình xác thực và quét số chỉ mục của một trình xác thực nhất định.
Để việc rút tiền được xử lý, người xác thực phải sử dụng thông tin xác thực 0x01, được biểu thị bằng địa chỉ ETH. Chỉ cho phép cặp khóa BLS thông tin xác thực 0x00 khi chuỗi đèn hiệu trực tuyến. Để bắt đầu rút tiền, người xác thực có thông tin xác thực 0x00 sẽ cần ký vào thông báo BLSToExecutionChange. Những thứ này sẽ được kích hoạt trong bản nâng cấp Capella. Sẽ có nhiều công cụ khác nhau được sử dụng để ký thông báo này và người xác thực có thể mong đợi sự hỗ trợ và hướng dẫn cho những công cụ này.
Việc quét trình xác nhận được thực hiện trên mỗi khối. Nếu không có 16 lần rút tiền để xử lý sau khi quét một tập hợp con của bộ trình xác thực, trình xác thực sẽ dừng quét và trình xác thực tiếp theo sẽ bắt đầu từ chỉ mục trình xác thực được quét cuối cùng.
Như thường lệ, sẽ có một số mạng thử nghiệm và mạng thử nghiệm dành cho nhà phát triển (thậm chí có thể là một số mạng thử nghiệm mới!) để người xác thực chạy toàn bộ quy trình và giải quyết mọi vướng mắc trước khi mạng chính đi vào hoạt động.
Thượng Hải/Capella không phải là bản nâng cấp duy nhất đang tiến triển! Nhóm nhà phát triển vẫn đang mong chờ bản nâng cấp tiếp theo.
nâng cấp Cancun
Vì nội dung của bản nâng cấp Thượng Hải đã đầy nên nhiều EIP (CFI) được xem xét nâng cấp đã không thể tham gia nâng cấp Thượng Hải. Nhóm khách hàng bắt đầu thảo luận về EIP nào nên được xem xét cho lần nâng cấp tiếp theo: nâng cấp Cancun (tên lớp đồng thuận sẽ được xác định)
Về lớp đồng thuận, EIP-4844 đã trở thành EIP đầu tiên được ghi vào đặc tả sau khi nâng cấp Capella. Chưa có (chưa) thông số kỹ thuật cho lớp điều hành có thể triển khai bố cục này, nhưng nhóm lớp điều hành đã đồng ý đi theo đường dẫn tương tự và tập trung vào EIP-4844 trong lần nâng cấp tiếp theo.
Theo quy ước nâng cấp bằng cách sử dụng tên của các thành phố nơi Devcon được tổ chức, cancun.md đã được tạo, với EIP-4844 chính thức được đưa vào bản nâng cấp.
Quyết định này xảy ra vào phút cuối của cuộc họp AllCoreDevs cuối cùng vào năm 2022, vì vậy không có thời gian để thực hiện các đề xuất khác. Các EIP đã tham gia nâng cấp CFI ở Thượng Hải nhưng cuối cùng không được đưa vào danh sách CFI để nâng cấp Cancun. Một bài đăng cũng đã được mở trên diễn đàn Ethereum Magicians để thảo luận về các EIP ứng cử viên ở Cancun. Các cuộc thảo luận về phạm vi nâng cấp ở Cancun sẽ bắt đầu một cách nghiêm túc vào đầu năm tới.
Lễ KZG
Một điều khác đáng mong đợi liên quan đến việc nâng cấp Cancun là Lễ KZG, đây là một yêu cầu của EIP-4844.
Nghi thức này sẽ tạo ra tính ngẫu nhiên cần thiết để xác minh tính hợp lệ của dữ liệu blob. Để nó được coi là an toàn, chỉ một người tham gia cần phải trung thực. Nói cách khác, nếu tất cả trừ một trong những người tham gia thông đồng với nhau thì toàn bộ quá trình sẽ được bảo mật bằng mật mã.
Buổi lễ bắt đầu vào tháng Giêng và sẽ mở cửa cho tất cả mọi người trong vài tháng. Với mục tiêu 10.000 người tham gia, đây được lên kế hoạch là buổi lễ lớn nhất thuộc loại này cho đến nay! Nếu bạn muốn chắc chắn rằng mình không bỏ lỡ, hãy theo dõi Trent Van Epps trên Twitter!
Quá trình nâng cấp sau sáp nhập
Như đã đề cập trong bản cập nhật trước, sau khi sáp nhập, việc điều phối quá trình nâng cấp Ethereum ở lớp thực thi và lớp đồng thuận là một việc cần làm quan trọng. Từ góc độ cấp cao, lớp thực thi sử dụng Yellow Paper & EIP để mô tả các sửa đổi, trong khi lớp đồng thuận sử dụng các thông số kỹ thuật Python có thể thực thi được.
Lợi ích của quy trình cấp điều hành là EIP được cộng đồng biết đến rộng rãi và được định dạng theo cách thể hiện rõ ràng lý do đằng sau đề xuất. Những cuốn sách màu vàng có nhiều nội dung toán học được ghép nối với EIP và nhu cầu đưa các thông số kỹ thuật trở lại ngữ cảnh của từng EIP, khiến các thông số kỹ thuật của lớp thực thi khó hiểu và khó mở rộng.
Vấn đề với lớp đồng thuận thì ngược lại: nó có đặc tả rõ ràng và dễ hiểu trong một kho lưu trữ duy nhất, nhưng những thay đổi không hữu hình và các đề xuất bị chôn vùi trong các PR công khai khác trong kho lưu trữ.
Với việc giới thiệu đặc tả lớp thực thi Ethereum, chúng tôi hy vọng sẽ rút ngắn khoảng cách này từ phía lớp thực thi. Và, với một số vấn đề về quy trình, chúng tôi có thể đưa EIP vào quy trình lớp đồng thuận!
Điều đó nói lên rằng, khi phạm vi nâng cấp Thượng Hải đã được thảo luận và hoàn tất, rõ ràng là một phần khác của quy trình có thể bị thiếu: cho phép cộng đồng bày tỏ sở thích tương đối của họ đối với các thay đổi và tham gia thảo luận về toàn bộ phạm vi nâng cấp (thay vì các EIP riêng lẻ) Hãy thảo luận vấn đề này tại chỗ và biến nó thành một phần của AllCoreDevs và các quyết định trong cuộc họp lớp đồng thuận.
Vẫn chưa rõ nó sẽ trông như thế nào – Tôi rất muốn có đề xuất! — nhưng khi số lượng bên liên quan tích cực tham gia vào các thay đổi giao thức tăng lên, cũng như số lượng khu vực bị ảnh hưởng bởi những thay đổi của lớp 1, rõ ràng là chúng tôi cần thứ gì đó.
May mắn thay, chúng ta không cần phải bắt đầu lại từ đầu. Ethereum Magicians đã tồn tại được nhiều năm và các cuộc gặp gỡ ngoại tuyến, cuộc họp nhóm chuyên dụng hoặc cuộc họp cộng đồng có thể là điểm khởi đầu tốt cho việc mở rộng.
Mong đợi nhiều tiến bộ hơn trên mặt trận này vào đầu năm 2023!
Cập nhật Hiệp hội Hiệp hội
Với việc thử nghiệm Protocol Guild (PG) hiện đã đi được nửa chặng đường, họ đã phát hành một báo cáo để xem mọi thứ đang diễn ra như thế nào và xem xét các bước tiếp theo cho dự án.
Xin nhắc lại, PG là một cơ chế tài trợ không cần cấp phép dành cho các nhà phát triển ứng dụng khách Ethereum Lớp 1, nhà nghiên cứu giao thức và những người đóng góp hỗ trợ (như bạn).
Cơ chế này tập trung vào cá nhân chứ không phải tổ chức. Tóm lại, mỗi thành viên đủ điều kiện nhận một phần token của bang hội, được tính trọng số dựa trên thời gian họ đã đóng góp cho Ethereum. Việc bổ sung và xóa các thành viên được thực hiện theo cách Ethereum thực sự - dựa trên một bộ tiêu chuẩn và sự đồng thuận sơ bộ trong PG. Danh sách này sau đó sẽ được đưa vào chuỗi bằng cách sử dụng hợp đồng phân chia 0xSplit. Sau đó, nhà tài trợ có thể gửi tiền trực tiếp đến địa chỉ của người nhận hoặc đến một hợp đồng trao quyền giải phóng tiền đến địa chỉ của người nhận.
Báo cáo tạm thời thí điểm được tóm tắt trong tweet này. Dưới đây là một số điểm nổi bật
Chương trình thí điểm đã huy động được 9,7 triệu USD từ các tổ chức như Lido, Uniswap, ENS, NounsDAO và MolochDAO, cũng như các nhà tài trợ thường xuyên từ các cá nhân (cảm ơn Tetranode!) - cảm ơn mọi người vì đã biến điều này thành hiện thực!
PG có 90 thành viên khi mới ra mắt và hiện có 128 thành viên, với 5 triệu USD được phân bổ giữa họ
Trung bình mỗi thành viên nhận được 39.000 USD, thấp nhất là 13.000 USD và cao nhất là 79.000 USD.
Kiến trúc của PG đang thay đổi và sẽ hỗ trợ L2 cũng như loại bỏ nhu cầu sử dụng nhiều chữ ký để cập nhật trọng số
Những kết quả ban đầu này cho thấy PG đang hoạt động theo kế hoạch: một cơ chế phân phối một rổ token cho một nhóm những người đóng góp giao thức đang tự ươm tạo và đang phát triển. Dự án này sẽ không được như ngày nay nếu không có sự hỗ trợ hào phóng của các nhà tài trợ thí điểm.
Nhìn về tương lai, bây giờ là lúc để mở rộng phạm vi tiếp cận của PG và nhận ra toàn bộ tiềm năng của nó: cung cấp cho những người duy trì Ethereum khoản bồi thường cạnh tranh, được điều chỉnh theo rủi ro. Điều dễ dàng nhất có thể làm ở đây là dự án sẽ quyên góp cho PG ngay từ đầu, như Danny Ryan đã nói trong tweet ra mắt PG.
Hầu hết số tiền quyên góp trong thí điểm đều đến từ các dự án lớn với số tiền tài trợ lớn. Nếu Hiệp hội Giao thức có thể thuyết phục các dự án này quyên góp cho PG ngay từ ngày đầu tiên, khi mã thông báo của họ vẫn thực sự “vô giá trị”, thì những người duy trì Ethereum có thể được hưởng lợi từ toàn bộ quỹ đạo đi lên của các dự án thành công này.
Khi có đủ dự án tham gia, các biện pháp khuyến khích có thể giữ chân những tài năng giỏi nhất theo thỏa thuận bảo trì thay vì kéo họ đi.
Để hỗ trợ điều này và nhiều hình thức quyên góp khác, PG sẽ cần đại tu về mặt công nghệ. Phiên bản tiếp theo sẽ hỗ trợ L1 và L2, đồng thời giảm hơn nữa dấu chân quản trị trên chuỗi.
Nếu bạn là một dự án muốn quyên góp cho Protocol Guild, vui lòng liên hệ với tôi - DM của tôi đã mở!
Theo sát
Thế là kết thúc năm 2022... Thật là một năm phi thường! Ba tháng trước, chúng tôi thậm chí còn chưa hợp nhất! Giờ đây, Ethereum có bằng chứng cổ phần đang lặng lẽ chạy ẩn, trọng tâm đã chuyển sang các giao dịch trong tương lai.
Khi mọi người trở lại vào tháng 1, bạn có thể mong đợi:
Shanghai/Capella đã nâng cấp mạng thử nghiệm dành cho nhà phát triển và Shadow Fork
Lễ KZG được trực tuyến
Các cuộc thảo luận xung quanh Cancun và quá trình nâng cấp mạng sẽ phát triển như thế nào để nắm bắt tốt hơn sở thích của cộng đồng
Chương trình thử nghiệm bang hội giao thức sẽ kết thúc và chúng tôi sẽ công bố cấu trúc sau thử nghiệm.