Bài viết này chủ yếu giới thiệu lịch sử quản trị của EIP-2537, khám phá lý do tại sao sau 5 năm mới đưa đề xuất này vào nâng cấp.
撰文：shew
Tóm tắt
EIP-2537 là hướng dẫn EVM pre-assembly được xác định thêm trong bản nâng cấp phân nhánh mới nhất của Pectra. Hướng dẫn này bổ sung nhiều chức năng tính toán cho đường cong BLS12-381 cho EVM, chẳng hạn như tính toán ghép nối trên miền đường cong.
EIP-2573 được đề xuất lần đầu vào năm 2020 và phải đến năm 2025 mới được xác nhận sẽ được đưa vào nâng cấp Ethereum. Bài viết này chủ yếu giới thiệu lịch sử quản trị của EIP-2537, khám phá lý do tại sao phải mất 5 năm để đề xuất này được đưa vào nâng cấp.
Bối cảnh đề xuất
Vào tháng 1 năm 2017, Vitalik Buterin đã lần đầu tiên giới thiệu thuật toán cặp và đường cong alt_bn128 trong Exploring Elliptic Curve Pairings. Sau đó, vào tháng 2 năm 2017, Vitalik Buterin và Christian Reitwiessner đã đề xuất các đề xuất EIP-196 và EIP-197, nội dung đề xuất là thêm hỗ trợ tính toán đường cong alt_bn128 vào EVM.
Trong bản nâng cấp Byzantium vào tháng 10 năm 2017, đã chính thức đưa vào đường cong alt_bn128. Nói một cách đơn giản, alt_bn128 lần đầu tiên thực hiện tính toán cặp miền đường cong bên trong EVM, điều này cho phép xác thực chứng minh ZK-Snarks có thể được thực hiện trong EVM.
Nhưng với sự phát triển của mật mã, vào tháng 11 năm 2017, nhóm phát triển zcash lần đầu tiên đã đưa ra đường cong BLS12-381 trong tài liệu BLS12-381: New zk-SNARK Elliptic Curve Construction. So với alt_bn128, BLS12-381 có độ an toàn cao hơn và hiệu suất tốt hơn. Rất nhiều giao thức blockchain sau đó đã sử dụng đường cong BLS12-381 và bỏ qua đường cong alt_bn128.
Vào tháng 5 năm 2018, Justin Drake đã xuất bản bài viết "Tổng hợp chữ ký thực tiễn với BLS" trên ethresear, chỉ ra rằng trong các bản nâng cấp PoS và phân mảnh trong tương lai của Ethereum có thể sử dụng thuật toán đa chữ ký BLS dựa trên đường cong BLS12-381. Vào thời điểm đó, các nhà nghiên cứu Ethereum hy vọng sử dụng EIP-1011 để giải quyết vấn đề lớp đồng thuận, nhưng kế hoạch EIP-1011 chỉ có thể chứa tối đa 900 người xác thực, do đó đã đặt ra quy mô đặt cọc khổng lồ 1500 ETH cho mỗi người xác thực. Với việc đề xuất kế hoạch đa chữ ký BLS, EIP-1011 đã rút khỏi sân khấu lịch sử. Thực tế đã chứng minh rằng bản nâng cấp ETH2 sau này cũng cuối cùng đã sử dụng đường cong BLS12-381.
Cùng với sự phát triển của ETH2, BLS12-381 được sử dụng trong ETH2 đã bắt đầu được kêu gọi cho lớp thực thi ETH. Vào tháng 2 năm 2020, một số nhà nghiên cứu đã đưa ra EIP-2537 và hy vọng rằng đề xuất này có thể được thử nghiệm cùng với mạng thử nghiệm ETH2. Tác giả của EIP-2537, Alex Stokes, đã kêu gọi đưa EIP-2537 vào trong hard fork Berlin trong bài viết "What eth2 needs from eth1 over the next six months".
Thú vị là, tác giả của EIP-2537 cũng là đồng sáng lập của Matter Labs, trong đó sản phẩm nổi tiếng nhất của Matter Labs chính là ZKSync
Berlin bất ổn
Trước khi giới thiệu nội dung tiếp theo, chúng ta cần giới thiệu EIP-1962. EIP-1962 là đề xuất đầu tiên về việc lập trình sẵn chuẩn bị miền cặp đường cong elip do Matter Labs đưa ra vào tháng 4 năm 2019, đề xuất này hỗ trợ ba đường cong, cụ thể là:
BLS12
BN
MNT4/6 (Ate pairing)
EIP này chuẩn bị tăng thêm 10 lệnh lập trình trước để xử lý các đường cong khác nhau. Tuy nhiên, sau khi đề xuất này ra đời, một số lượng đáng kể các nhà phát triển đã đặt câu hỏi rằng đề xuất này quá phức tạp đến mức khó thực hiện đối với các nhà phát triển. Đồng thời, do EIP1962 được tổng quát hóa cao, việc gọi cũng rất phiền phức đối với các kỹ sư hợp đồng thông minh. Tất nhiên, với tư cách là người đề xuất EIP-1962, Matter Labs thực chất đã hoàn thành công việc phát triển thuật toán elip và cung cấp các triển khai tham khảo bằng Rust / Go / C++.
Để giải quyết vấn đề EIP-1962, Matter Labs đã đề xuất nhiều EIP tách ra từ EIP-1962 vào tháng 2 năm 2020, những EIP này đều phần nào kế thừa giao diện của EIP-1962. Những EIP này bao gồm:
EIP-2537 cung cấp hỗ trợ cho BLS12-381
EIP-2539 cung cấp hỗ trợ BLS12-377
PR#2541 cung cấp BLS12-377 (Zexe curve) hỗ trợ, nhưng lưu ý rằng đề xuất này cuối cùng không nhận được số EIP, không thể tìm thấy trên trang web tài liệu EIP.
Trong số các EIP này, quan trọng nhất là EIP-2537, vì lớp đồng thuận cũng sử dụng đường cong BLS12-381. Mục tiêu cốt lõi của EIP-1962 và EIP-2537 đều là để thực hiện xác minh chữ ký BLS của lớp đồng thuận trong mạng chính. Vào thời điểm đó, ETH2 đang phát triển thiết kế hợp đồng gửi tiền cho lớp đồng thuận. Trong thiết kế ban đầu của hợp đồng gửi tiền, do lớp thực thi không bao gồm thuật toán xác minh BLS, nên hợp đồng gửi tiền sẽ không xác minh chữ ký, chữ ký BLS cụ thể sẽ được lớp đồng thuận xác minh sau khi người dùng gửi tiền, nếu phát hiện không chính xác (đối với các xác nhận viên mới), tiền gửi sẽ thất bại và ETH mà người dùng gửi vào sẽ bị mất.
Trong bối cảnh này, các nhà phát triển cốt lõi mong muốn đưa vào BLS12-381 để thực hiện xác minh chữ ký trong hợp đồng gửi tiền, nhằm tránh khả năng mất mát tài sản ETH2 của người dùng. Đây cũng là lý do mà nhiều nhà phát triển quan tâm đến EIP-1962 và EIP-2537 vào thời điểm đó.
Khi EIP-2537 vừa được đề xuất, Vitalik đã ngay lập tức phát hiện ra một loạt vấn đề tồn tại trong EIP:
Các truy vấn này tập trung vào nội dung của tài liệu EIP, sau đó được các tác giả EIP trả lời và thảo luận. Sau đó, vào ngày 6 tháng 3 năm 2020, tại Hội nghị các nhà phát triển Ethereum Core # 82, EIP-2537 đã được thảo luận bởi các nhà phát triển cốt lõi Ethereum. Trong phiên này, Vitalik lập luận rằng các EIP như EIP-2537 rất hiệu quả đối với các bằng chứng SNARK đệ quy và không làm hỏng Ethereum về lâu dài. Đồng thời, ưu tiên của EIP-2537 đã được xác nhận và tất cả các khách hàng đã đồng ý thực hiện EIP-2537 càng sớm càng tốt và có kế hoạch hoàn thành tất cả các phát triển trước khi nâng cấp Berlin.
Sau đó, EIP-2537 trở thành ưu tiên cao hơn. Vào ngày 20 tháng 3 năm 2020, tại Hội nghị các nhà phát triển Ethereum Core # 83, EIP-2537 vẫn là đề xuất đầu tiên được thảo luận. Cuộc họp đã xác nhận rằng EIP-2537 đã thay thế EIP-1962 là đề xuất BLS cốt lõi và trở thành danh sách EIP được lựa chọn trước để nâng cấp của Berlin ( tức là (EFI)) đủ điều kiện để hòa nhập.
Tại cuộc họp Ethereum Core Devs Meeting #84 vào tháng 4 năm 2020, cuộc họp đã chính thức đưa EIP-2537 vào nâng cấp hard fork Berlin và xác định thời gian nâng cấp Berlin sẽ được thực hiện vào tháng 4 và thử nghiệm vào tháng 5 - 6. Đáng chú ý, trong cuộc thảo luận này, EIP-2537 được liệt kê là vấn đề ưu tiên hàng đầu.
Sau đó, EIP-2537 bước vào một số lượng lớn các giai đoạn phát triển và thử nghiệm, và trong gần 20 cuộc họp nhà phát triển cốt lõi tiếp theo, mỗi cuộc họp về cơ bản đều liên quan đến việc thảo luận về EIP-2537. Tiếp theo, chúng ta hãy xem những câu hỏi nào về EIP-2537 đã được thảo luận trong mỗi cuộc họp.
Tại cuộc họp các nhà phát triển lõi Ethereum #85, Danno và Axic đã thảo luận về vấn đề mã hóa ABI của EIP-2537. Sau đó, các nhà phát triển lõi đã đồng bộ hóa tình hình thực hiện hiện tại, trong đó do người đề xuất EIP-2537 là Matter Labs trước đó đã hoàn thành cơ bản phiên bản Rust, nên khách hàng Besu tuyên bố đã thực hiện cơ bản chức năng của EIP-2537, nhưng phía Geth cho biết hiện tại không ai đang làm việc cho việc thực hiện EIP-2537.
Tại cuộc họp các nhà phát triển Core của Ethereum #86, các triển khai nút Ethereum khác nhau đã đồng bộ hóa lại tình hình thực hiện EIP-2537, trong đó Geth cho biết đã hoàn thành một phần công việc, nhưng còn rất nhiều công việc chờ hoàn thành.
Trong cuộc họp các nhà phát triển Ethereum Core Devs Meeting #87, nội dung cốt lõi của cuộc họp là vấn đề thực hiện EIP-2537. Các nhà phát triển Geth cho biết hiện có một PR dài 16000 dòng thực hiện EIP-2537, nhưng các nhà phát triển Geth không thể xác định PR có an toàn và hiệu quả trong việc thực hiện EIP-2537 hay không, vì vậy các nhà phát triển chỉ có thể đánh giá tình trạng mã thông qua việc kiểm tra mờ đơn giản.
Các nhà phát triển Geth nói:「Vì vậy, phản ứng trực giác của tôi là không có khả năng Geth sẽ sẵn sàng với các hoạt động đường cong BLS cho việc ra mắt mainnet vào tháng Bảy.」，tức là Geth có khả năng lớn không hoàn thành phát triển liên quan đến EIP-2537 trước thời gian dự kiến ở Berlin.
Hudson Jameson đề nghị tìm kiếm kỹ sư mật mã để hỗ trợ PR đánh giá cho Geth, và đề xuất sử dụng mạng thử nghiệm để kiểm tra tính an toàn của việc thực hiện EIP-2537. Bởi vì lúc này, đội phát triển ETH2 cũng đang thực hiện xác minh chữ ký BLS, nên đội ETH2 có thể tham gia vào việc kiểm tra.
Tại đây, chúng ta cần bổ sung một kiến thức nền tảng, đó là việc thực hiện PR EIP-2537 của Geth đã sử dụng rất nhiều mã assembly để đảm bảo hiệu quả, phần mã assembly này rất khó đọc và hiểu. Vì vậy, Alex Vlasov đã đề xuất loại bỏ các tối ưu hóa assembly phức tạp bên trong PR để giảm bớt độ khó trong việc xem xét.
Chúng tôi đã giới thiệu một mục tiêu cốt lõi của EIP-2537 là hỗ trợ hợp đồng gửi ETH2, nhưng trong cuộc họp lần này, các nhà phát triển hợp đồng gửi đã cho biết rằng hợp đồng gửi không sử dụng EIP-2537 đã được kiểm toán, vì vậy một số nhà phát triển đề xuất tốt nhất là không nên phát hành một hợp đồng gửi sử dụng EIP-2537.
Cuối cùng, hội nghị đã quyết định tăng cường mạng thử nghiệm YOLO, mà cốt lõi là để thử nghiệm EIP-2537. Trên thực tế, trong cuộc họp lần này, chúng ta có thể thấy tầm quan trọng của EIP-2537 đã giảm đáng kể kể từ khi hợp đồng gửi tiền được hoàn thành, trong khi các nhà phát triển Geth đã cho rằng EIP này rất có thể sẽ không được thực hiện trước khi nâng cấp Berlin. Dường như việc EIP-2537 không được chấp nhận trong nâng cấp Berlin đã trở thành điều không thể tránh khỏi.
Tại cuộc họp các nhà phát triển Ethereum Core Devs Meeting #88, các nhà phát triển Geth phát hiện ra rằng PR của việc triển khai EIP-2537 tồn tại một loạt vấn đề, các nhà phát triển cho biết cần phải thử nghiệm và sửa chữa thêm. Lúc này trong hệ thống Geth có hai triển khai EIP-2537, một triển khai bao gồm tối ưu hóa hợp ngữ, trong khi triển khai còn lại hoàn toàn được viết bằng ngôn ngữ go, có nhà phát triển đề xuất nên sử dụng phiên bản viết bằng ngôn ngữ go để giảm bớt độ khó của việc kiểm tra mã.
Tại cuộc họp các nhà phát triển cốt lõi của Ethereum #89, một vấn đề nghiêm trọng hơn đã xảy ra, thử nghiệm YOLO gặp phải một số vấn đề, các nhà phát triển nghi ngờ rằng đó là do chữ ký BLS gây ra, nhưng các nhà phát triển EIP2537 đã phản bác lại điều này, cho rằng vấn đề của mạng thử nghiệm không phải do chữ ký BLS gây ra. Tin tốt về EIP-2537 là hợp đồng gửi dựa trên EIP-2537 đã hoàn thành phát triển cơ bản, hợp đồng này đang chờ kiểm toán hợp đồng.
Trong cuộc họp Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, một nhà phát triển đã đề xuất sử dụng giải pháp mô-đun để giảm chi phí phát triển nhằm tăng cường sự đa dạng của khách hàng. Nếu độc giả quan tâm đến sự đa dạng của khách hàng Ethereum, có thể đọc lại biên bản của hai cuộc họp này.
Tại cuộc họp các nhà phát triển cốt lõi Ethereum #92, 2537 vẫn được xác nhận là EIP cần thiết cho nâng cấp Berlin.
Trong cuộc họp các nhà phát triển Ethereum Core #96, dựa trên Celo đã kết hợp EIP-2537 và EIP-2539 vào bản nâng cấp hard fork của mạng lưới, vì vậy Matter Labs muốn đưa EIP-2539, được đề xuất cùng với EIP-2537, vào thử nghiệm trên mạng thử nghiệm YOLO v2 và tiến vào nâng cấp Berlin. Tuy nhiên, các nhà phát triển Geth phản đối, cho rằng EIP-2537 hiện tại vẫn chưa được thử nghiệm đầy đủ trong Geth. Cuối cùng, cuộc họp quyết định không thêm 2696 vào nâng cấp Berlin, để lại cho các cuộc thảo luận trong tương lai.
Trong Ethereum Core Devs Meeting #99, người ta đã quyết định chuyển EIP-2537 ra khỏi testnet YOLO v3 và nâng cấp Berlin, lý do cốt lõi là EIP-2537 đã lãng phí quá nhiều thời gian cho các nhà phát triển cốt lõi và cản trở sự phát triển của các EIP khác trong bản nâng cấp Berlin. Yếu tố thứ hai là Ethereum Foundation đã đề xuất EVM384 thay thế cho EIP-2537, cung cấp một giải pháp tổng quát hơn để tính toán các đường cong elip. Tuy nhiên, các nhà phát triển cốt lõi bày tỏ lo ngại về bảo mật trong các cuộc thảo luận hội nghị.
Nội dung trên chính là quá trình đầu tiên của EIP-2537, chúng ta có thể thấy EIP-2537 ban đầu là một trong những EIP quan trọng nhất trong nâng cấp Berlin, nhưng do vấn đề thực hiện nên cuối cùng đã bị loại bỏ. Cuối cùng, vào tháng 4 năm 2021, Ethereum đã hoàn thành nâng cấp Berlin, trong đó các EIP cốt lõi như EIP-2565 thực tế đều không phức tạp, nhìn chung nâng cấp Berlin dường như hơi mỏng manh, điều này là do EIP-2537 phức tạp nhất đã bị loại khỏi nâng cấp Berlin.
Phát triển tiếp theo
Như mọi người đã biết, mỗi lần nâng cấp Ethereum đều có một đề xuất cốt lõi, chẳng hạn như nâng cấp London sau nâng cấp Berlin đã giới thiệu đề xuất phí quan trọng nhất trong lịch sử Ethereum EIP-1559. Đối với EIP-2537 từng là đề xuất cốt lõi, các lần nâng cấp sau này rất khó để đưa đề xuất này vào.
Trong bản nâng cấp London sau Berlin, các nhà phát triển đã đồng bộ hóa tình hình phát triển hiện tại của EIP-2537 trong issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. Lúc này, do việc sử dụng các thư viện khác để triển khai EIP-2537, đã dẫn đến một cuộc thảo luận về việc sử dụng gas cho EIP-2537. Đồng thời, một số nhà phát triển đã đề xuất thay thế EIP-2537 bằng EVM384. Tuy nhiên, trong cuộc họp Ethereum Core Devs Meeting #111 vào tháng 4 năm 2021, EIP-2537 đã bị loại bỏ khỏi bản nâng cấp London do độ phức tạp. Sự phức tạp chính nằm ở việc triển khai tiêu chuẩn EIP-2537 đã thay đổi thư viện phụ thuộc, điều này dẫn đến việc giá gas có thể thay đổi, và các triển khai của khách hàng khác nhau cần một khoảng thời gian đáng kể để đánh giá lại mức tiêu thụ gas.
Vào tháng 6 năm 2021, đã chính thức đề xuất việc đưa EIP-2537 vào bản nâng cấp Shanghai trong issues#343. Tuy nhiên, cần lưu ý rằng sau bản nâng cấp London, thực tế bản nâng cấp Pairs hay còn gọi là The Merge đã chiếm rất nhiều thời gian của các nhà phát triển, các nhà phát triển lớp thực thi cần viết rất nhiều mã để thực hiện nâng cấp PoS. Vào tháng 9 năm 2022, bản nâng cấp Pairs đã hoàn thành, các nhà phát triển lớp thực thi cuối cùng có cơ hội tiếp tục thảo luận về một số mục tiêu của bản nâng cấp Shanghai.
Vào tháng 11 năm 2022, trong cuộc họp Ethereum Core Devs Meeting #150, đã có một cuộc thảo luận ngắn về việc có nên đưa EIP-2537 vào nâng cấp Shanghai hay không, nhưng các nhà phát triển cho rằng EIP-2537 cần được hoãn lại, vì nâng cấp Shanghai chủ yếu hỗ trợ việc rút tiền PoS. Cuối cùng, EIP-2537 đã không được đưa vào nâng cấp Shanghai tập trung vào chức năng rút tiền.
Thậm chí còn thê thảm hơn là nâng cấp Cancun vẫn chưa thảo luận về EIP-2537, vì cốt lõi của nâng cấp Cancun là hỗ trợ EIP-4844 từ các nút lớp thực thi. EIP-4844 cung cấp Blob cho lớp hai của Ethereum để thuận tiện cho lớp hai sử dụng Ethereum làm lớp dữ liệu khả dụng.
Cuối cùng, trong cuộc họp Ethereum Core Devs Meeting #181 vào tháng 2 năm 2024, các nhà phát triển đã thảo luận về việc đưa EIP-2537 vào bản nâng cấp Pectra, và vào thời điểm này, các nhà phát triển cho rằng việc triển khai EIP-2537 không còn là vấn đề, chỉ có một số vấn đề liên quan đến cách định giá Gas tiêu thụ.
Tại cuộc họp Ethereum Core Devs vào ngày 19 tháng 12 năm 2024 #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, các nhà phát triển đã thảo luận về việc định giá lại BLS precompile, nhà phát triển Geth Jared Wasinger đã đề xuất tăng chi phí gas lên 20%, và nhận được sự hỗ trợ từ nhóm Besu trong việc kiểm tra hiệu suất.
Tóm tắt
Có thể thấy, việc EIP có được đưa vào nâng cấp Ethereum hay không "chắc chắn phải dựa vào nỗ lực tự thân, nhưng cũng cần xem xét đến hành trình lịch sử". Mỗi lần nâng cấp Ethereum đều có chủ đề riêng, giống như EIP-2537 từng là EIP quan trọng nhất trong nâng cấp Berlin, nhưng đã bị loại bỏ do độ khó và phức tạp trong việc thực hiện. Sau đó, Ethereum đã bước vào tiến trình lịch sử PoS, các EIP thuần thực thi phức tạp không được chú trọng, trong khi rất nhiều EIP thực thi liên quan đến PoS được coi là mục tiêu nâng cấp cốt lõi, điều này đã dẫn đến việc EIP-2537 không được chấp nhận trong một thời gian dài.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Quan sát quản trị Ethereum: Quá trình tiền biên dịch EIP-2537｜Nghiên cứu GCC
撰文：shew
Tóm tắt
EIP-2537 là hướng dẫn EVM pre-assembly được xác định thêm trong bản nâng cấp phân nhánh mới nhất của Pectra. Hướng dẫn này bổ sung nhiều chức năng tính toán cho đường cong BLS12-381 cho EVM, chẳng hạn như tính toán ghép nối trên miền đường cong.
EIP-2573 được đề xuất lần đầu vào năm 2020 và phải đến năm 2025 mới được xác nhận sẽ được đưa vào nâng cấp Ethereum. Bài viết này chủ yếu giới thiệu lịch sử quản trị của EIP-2537, khám phá lý do tại sao phải mất 5 năm để đề xuất này được đưa vào nâng cấp.
Bối cảnh đề xuất
Vào tháng 1 năm 2017, Vitalik Buterin đã lần đầu tiên giới thiệu thuật toán cặp và đường cong alt_bn128 trong Exploring Elliptic Curve Pairings. Sau đó, vào tháng 2 năm 2017, Vitalik Buterin và Christian Reitwiessner đã đề xuất các đề xuất EIP-196 và EIP-197, nội dung đề xuất là thêm hỗ trợ tính toán đường cong alt_bn128 vào EVM.
Trong bản nâng cấp Byzantium vào tháng 10 năm 2017, đã chính thức đưa vào đường cong alt_bn128. Nói một cách đơn giản, alt_bn128 lần đầu tiên thực hiện tính toán cặp miền đường cong bên trong EVM, điều này cho phép xác thực chứng minh ZK-Snarks có thể được thực hiện trong EVM.
Nhưng với sự phát triển của mật mã, vào tháng 11 năm 2017, nhóm phát triển zcash lần đầu tiên đã đưa ra đường cong BLS12-381 trong tài liệu BLS12-381: New zk-SNARK Elliptic Curve Construction. So với alt_bn128, BLS12-381 có độ an toàn cao hơn và hiệu suất tốt hơn. Rất nhiều giao thức blockchain sau đó đã sử dụng đường cong BLS12-381 và bỏ qua đường cong alt_bn128.
Vào tháng 5 năm 2018, Justin Drake đã xuất bản bài viết "Tổng hợp chữ ký thực tiễn với BLS" trên ethresear, chỉ ra rằng trong các bản nâng cấp PoS và phân mảnh trong tương lai của Ethereum có thể sử dụng thuật toán đa chữ ký BLS dựa trên đường cong BLS12-381. Vào thời điểm đó, các nhà nghiên cứu Ethereum hy vọng sử dụng EIP-1011 để giải quyết vấn đề lớp đồng thuận, nhưng kế hoạch EIP-1011 chỉ có thể chứa tối đa 900 người xác thực, do đó đã đặt ra quy mô đặt cọc khổng lồ 1500 ETH cho mỗi người xác thực. Với việc đề xuất kế hoạch đa chữ ký BLS, EIP-1011 đã rút khỏi sân khấu lịch sử. Thực tế đã chứng minh rằng bản nâng cấp ETH2 sau này cũng cuối cùng đã sử dụng đường cong BLS12-381.
Cùng với sự phát triển của ETH2, BLS12-381 được sử dụng trong ETH2 đã bắt đầu được kêu gọi cho lớp thực thi ETH. Vào tháng 2 năm 2020, một số nhà nghiên cứu đã đưa ra EIP-2537 và hy vọng rằng đề xuất này có thể được thử nghiệm cùng với mạng thử nghiệm ETH2. Tác giả của EIP-2537, Alex Stokes, đã kêu gọi đưa EIP-2537 vào trong hard fork Berlin trong bài viết "What eth2 needs from eth1 over the next six months".
Thú vị là, tác giả của EIP-2537 cũng là đồng sáng lập của Matter Labs, trong đó sản phẩm nổi tiếng nhất của Matter Labs chính là ZKSync
Berlin bất ổn
Trước khi giới thiệu nội dung tiếp theo, chúng ta cần giới thiệu EIP-1962. EIP-1962 là đề xuất đầu tiên về việc lập trình sẵn chuẩn bị miền cặp đường cong elip do Matter Labs đưa ra vào tháng 4 năm 2019, đề xuất này hỗ trợ ba đường cong, cụ thể là:
EIP này chuẩn bị tăng thêm 10 lệnh lập trình trước để xử lý các đường cong khác nhau. Tuy nhiên, sau khi đề xuất này ra đời, một số lượng đáng kể các nhà phát triển đã đặt câu hỏi rằng đề xuất này quá phức tạp đến mức khó thực hiện đối với các nhà phát triển. Đồng thời, do EIP1962 được tổng quát hóa cao, việc gọi cũng rất phiền phức đối với các kỹ sư hợp đồng thông minh. Tất nhiên, với tư cách là người đề xuất EIP-1962, Matter Labs thực chất đã hoàn thành công việc phát triển thuật toán elip và cung cấp các triển khai tham khảo bằng Rust / Go / C++.
Để giải quyết vấn đề EIP-1962, Matter Labs đã đề xuất nhiều EIP tách ra từ EIP-1962 vào tháng 2 năm 2020, những EIP này đều phần nào kế thừa giao diện của EIP-1962. Những EIP này bao gồm:
Trong số các EIP này, quan trọng nhất là EIP-2537, vì lớp đồng thuận cũng sử dụng đường cong BLS12-381. Mục tiêu cốt lõi của EIP-1962 và EIP-2537 đều là để thực hiện xác minh chữ ký BLS của lớp đồng thuận trong mạng chính. Vào thời điểm đó, ETH2 đang phát triển thiết kế hợp đồng gửi tiền cho lớp đồng thuận. Trong thiết kế ban đầu của hợp đồng gửi tiền, do lớp thực thi không bao gồm thuật toán xác minh BLS, nên hợp đồng gửi tiền sẽ không xác minh chữ ký, chữ ký BLS cụ thể sẽ được lớp đồng thuận xác minh sau khi người dùng gửi tiền, nếu phát hiện không chính xác (đối với các xác nhận viên mới), tiền gửi sẽ thất bại và ETH mà người dùng gửi vào sẽ bị mất.
Trong bối cảnh này, các nhà phát triển cốt lõi mong muốn đưa vào BLS12-381 để thực hiện xác minh chữ ký trong hợp đồng gửi tiền, nhằm tránh khả năng mất mát tài sản ETH2 của người dùng. Đây cũng là lý do mà nhiều nhà phát triển quan tâm đến EIP-1962 và EIP-2537 vào thời điểm đó.
Khi EIP-2537 vừa được đề xuất, Vitalik đã ngay lập tức phát hiện ra một loạt vấn đề tồn tại trong EIP:
Các truy vấn này tập trung vào nội dung của tài liệu EIP, sau đó được các tác giả EIP trả lời và thảo luận. Sau đó, vào ngày 6 tháng 3 năm 2020, tại Hội nghị các nhà phát triển Ethereum Core # 82, EIP-2537 đã được thảo luận bởi các nhà phát triển cốt lõi Ethereum. Trong phiên này, Vitalik lập luận rằng các EIP như EIP-2537 rất hiệu quả đối với các bằng chứng SNARK đệ quy và không làm hỏng Ethereum về lâu dài. Đồng thời, ưu tiên của EIP-2537 đã được xác nhận và tất cả các khách hàng đã đồng ý thực hiện EIP-2537 càng sớm càng tốt và có kế hoạch hoàn thành tất cả các phát triển trước khi nâng cấp Berlin.
Sau đó, EIP-2537 trở thành ưu tiên cao hơn. Vào ngày 20 tháng 3 năm 2020, tại Hội nghị các nhà phát triển Ethereum Core # 83, EIP-2537 vẫn là đề xuất đầu tiên được thảo luận. Cuộc họp đã xác nhận rằng EIP-2537 đã thay thế EIP-1962 là đề xuất BLS cốt lõi và trở thành danh sách EIP được lựa chọn trước để nâng cấp của Berlin ( tức là (EFI)) đủ điều kiện để hòa nhập.
Tại cuộc họp Ethereum Core Devs Meeting #84 vào tháng 4 năm 2020, cuộc họp đã chính thức đưa EIP-2537 vào nâng cấp hard fork Berlin và xác định thời gian nâng cấp Berlin sẽ được thực hiện vào tháng 4 và thử nghiệm vào tháng 5 - 6. Đáng chú ý, trong cuộc thảo luận này, EIP-2537 được liệt kê là vấn đề ưu tiên hàng đầu.
Sau đó, EIP-2537 bước vào một số lượng lớn các giai đoạn phát triển và thử nghiệm, và trong gần 20 cuộc họp nhà phát triển cốt lõi tiếp theo, mỗi cuộc họp về cơ bản đều liên quan đến việc thảo luận về EIP-2537. Tiếp theo, chúng ta hãy xem những câu hỏi nào về EIP-2537 đã được thảo luận trong mỗi cuộc họp.
Tại cuộc họp các nhà phát triển lõi Ethereum #85, Danno và Axic đã thảo luận về vấn đề mã hóa ABI của EIP-2537. Sau đó, các nhà phát triển lõi đã đồng bộ hóa tình hình thực hiện hiện tại, trong đó do người đề xuất EIP-2537 là Matter Labs trước đó đã hoàn thành cơ bản phiên bản Rust, nên khách hàng Besu tuyên bố đã thực hiện cơ bản chức năng của EIP-2537, nhưng phía Geth cho biết hiện tại không ai đang làm việc cho việc thực hiện EIP-2537.
Tại cuộc họp các nhà phát triển Core của Ethereum #86, các triển khai nút Ethereum khác nhau đã đồng bộ hóa lại tình hình thực hiện EIP-2537, trong đó Geth cho biết đã hoàn thành một phần công việc, nhưng còn rất nhiều công việc chờ hoàn thành.
Trong cuộc họp các nhà phát triển Ethereum Core Devs Meeting #87, nội dung cốt lõi của cuộc họp là vấn đề thực hiện EIP-2537. Các nhà phát triển Geth cho biết hiện có một PR dài 16000 dòng thực hiện EIP-2537, nhưng các nhà phát triển Geth không thể xác định PR có an toàn và hiệu quả trong việc thực hiện EIP-2537 hay không, vì vậy các nhà phát triển chỉ có thể đánh giá tình trạng mã thông qua việc kiểm tra mờ đơn giản.
Các nhà phát triển Geth nói:「Vì vậy, phản ứng trực giác của tôi là không có khả năng Geth sẽ sẵn sàng với các hoạt động đường cong BLS cho việc ra mắt mainnet vào tháng Bảy.」，tức là Geth có khả năng lớn không hoàn thành phát triển liên quan đến EIP-2537 trước thời gian dự kiến ở Berlin.
Hudson Jameson đề nghị tìm kiếm kỹ sư mật mã để hỗ trợ PR đánh giá cho Geth, và đề xuất sử dụng mạng thử nghiệm để kiểm tra tính an toàn của việc thực hiện EIP-2537. Bởi vì lúc này, đội phát triển ETH2 cũng đang thực hiện xác minh chữ ký BLS, nên đội ETH2 có thể tham gia vào việc kiểm tra.
Tại đây, chúng ta cần bổ sung một kiến thức nền tảng, đó là việc thực hiện PR EIP-2537 của Geth đã sử dụng rất nhiều mã assembly để đảm bảo hiệu quả, phần mã assembly này rất khó đọc và hiểu. Vì vậy, Alex Vlasov đã đề xuất loại bỏ các tối ưu hóa assembly phức tạp bên trong PR để giảm bớt độ khó trong việc xem xét.
Chúng tôi đã giới thiệu một mục tiêu cốt lõi của EIP-2537 là hỗ trợ hợp đồng gửi ETH2, nhưng trong cuộc họp lần này, các nhà phát triển hợp đồng gửi đã cho biết rằng hợp đồng gửi không sử dụng EIP-2537 đã được kiểm toán, vì vậy một số nhà phát triển đề xuất tốt nhất là không nên phát hành một hợp đồng gửi sử dụng EIP-2537.
Cuối cùng, hội nghị đã quyết định tăng cường mạng thử nghiệm YOLO, mà cốt lõi là để thử nghiệm EIP-2537. Trên thực tế, trong cuộc họp lần này, chúng ta có thể thấy tầm quan trọng của EIP-2537 đã giảm đáng kể kể từ khi hợp đồng gửi tiền được hoàn thành, trong khi các nhà phát triển Geth đã cho rằng EIP này rất có thể sẽ không được thực hiện trước khi nâng cấp Berlin. Dường như việc EIP-2537 không được chấp nhận trong nâng cấp Berlin đã trở thành điều không thể tránh khỏi.
Tại cuộc họp các nhà phát triển Ethereum Core Devs Meeting #88, các nhà phát triển Geth phát hiện ra rằng PR của việc triển khai EIP-2537 tồn tại một loạt vấn đề, các nhà phát triển cho biết cần phải thử nghiệm và sửa chữa thêm. Lúc này trong hệ thống Geth có hai triển khai EIP-2537, một triển khai bao gồm tối ưu hóa hợp ngữ, trong khi triển khai còn lại hoàn toàn được viết bằng ngôn ngữ go, có nhà phát triển đề xuất nên sử dụng phiên bản viết bằng ngôn ngữ go để giảm bớt độ khó của việc kiểm tra mã.
Tại cuộc họp các nhà phát triển cốt lõi của Ethereum #89, một vấn đề nghiêm trọng hơn đã xảy ra, thử nghiệm YOLO gặp phải một số vấn đề, các nhà phát triển nghi ngờ rằng đó là do chữ ký BLS gây ra, nhưng các nhà phát triển EIP2537 đã phản bác lại điều này, cho rằng vấn đề của mạng thử nghiệm không phải do chữ ký BLS gây ra. Tin tốt về EIP-2537 là hợp đồng gửi dựa trên EIP-2537 đã hoàn thành phát triển cơ bản, hợp đồng này đang chờ kiểm toán hợp đồng.
Trong cuộc họp Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, một nhà phát triển đã đề xuất sử dụng giải pháp mô-đun để giảm chi phí phát triển nhằm tăng cường sự đa dạng của khách hàng. Nếu độc giả quan tâm đến sự đa dạng của khách hàng Ethereum, có thể đọc lại biên bản của hai cuộc họp này.
Tại cuộc họp các nhà phát triển cốt lõi Ethereum #92, 2537 vẫn được xác nhận là EIP cần thiết cho nâng cấp Berlin.
Trong cuộc họp các nhà phát triển Ethereum Core #96, dựa trên Celo đã kết hợp EIP-2537 và EIP-2539 vào bản nâng cấp hard fork của mạng lưới, vì vậy Matter Labs muốn đưa EIP-2539, được đề xuất cùng với EIP-2537, vào thử nghiệm trên mạng thử nghiệm YOLO v2 và tiến vào nâng cấp Berlin. Tuy nhiên, các nhà phát triển Geth phản đối, cho rằng EIP-2537 hiện tại vẫn chưa được thử nghiệm đầy đủ trong Geth. Cuối cùng, cuộc họp quyết định không thêm 2696 vào nâng cấp Berlin, để lại cho các cuộc thảo luận trong tương lai.
Trong Ethereum Core Devs Meeting #99, người ta đã quyết định chuyển EIP-2537 ra khỏi testnet YOLO v3 và nâng cấp Berlin, lý do cốt lõi là EIP-2537 đã lãng phí quá nhiều thời gian cho các nhà phát triển cốt lõi và cản trở sự phát triển của các EIP khác trong bản nâng cấp Berlin. Yếu tố thứ hai là Ethereum Foundation đã đề xuất EVM384 thay thế cho EIP-2537, cung cấp một giải pháp tổng quát hơn để tính toán các đường cong elip. Tuy nhiên, các nhà phát triển cốt lõi bày tỏ lo ngại về bảo mật trong các cuộc thảo luận hội nghị.
Nội dung trên chính là quá trình đầu tiên của EIP-2537, chúng ta có thể thấy EIP-2537 ban đầu là một trong những EIP quan trọng nhất trong nâng cấp Berlin, nhưng do vấn đề thực hiện nên cuối cùng đã bị loại bỏ. Cuối cùng, vào tháng 4 năm 2021, Ethereum đã hoàn thành nâng cấp Berlin, trong đó các EIP cốt lõi như EIP-2565 thực tế đều không phức tạp, nhìn chung nâng cấp Berlin dường như hơi mỏng manh, điều này là do EIP-2537 phức tạp nhất đã bị loại khỏi nâng cấp Berlin.
Phát triển tiếp theo
Như mọi người đã biết, mỗi lần nâng cấp Ethereum đều có một đề xuất cốt lõi, chẳng hạn như nâng cấp London sau nâng cấp Berlin đã giới thiệu đề xuất phí quan trọng nhất trong lịch sử Ethereum EIP-1559. Đối với EIP-2537 từng là đề xuất cốt lõi, các lần nâng cấp sau này rất khó để đưa đề xuất này vào.
Trong bản nâng cấp London sau Berlin, các nhà phát triển đã đồng bộ hóa tình hình phát triển hiện tại của EIP-2537 trong issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. Lúc này, do việc sử dụng các thư viện khác để triển khai EIP-2537, đã dẫn đến một cuộc thảo luận về việc sử dụng gas cho EIP-2537. Đồng thời, một số nhà phát triển đã đề xuất thay thế EIP-2537 bằng EVM384. Tuy nhiên, trong cuộc họp Ethereum Core Devs Meeting #111 vào tháng 4 năm 2021, EIP-2537 đã bị loại bỏ khỏi bản nâng cấp London do độ phức tạp. Sự phức tạp chính nằm ở việc triển khai tiêu chuẩn EIP-2537 đã thay đổi thư viện phụ thuộc, điều này dẫn đến việc giá gas có thể thay đổi, và các triển khai của khách hàng khác nhau cần một khoảng thời gian đáng kể để đánh giá lại mức tiêu thụ gas.
Vào tháng 6 năm 2021, đã chính thức đề xuất việc đưa EIP-2537 vào bản nâng cấp Shanghai trong issues#343. Tuy nhiên, cần lưu ý rằng sau bản nâng cấp London, thực tế bản nâng cấp Pairs hay còn gọi là The Merge đã chiếm rất nhiều thời gian của các nhà phát triển, các nhà phát triển lớp thực thi cần viết rất nhiều mã để thực hiện nâng cấp PoS. Vào tháng 9 năm 2022, bản nâng cấp Pairs đã hoàn thành, các nhà phát triển lớp thực thi cuối cùng có cơ hội tiếp tục thảo luận về một số mục tiêu của bản nâng cấp Shanghai.
Vào tháng 11 năm 2022, trong cuộc họp Ethereum Core Devs Meeting #150, đã có một cuộc thảo luận ngắn về việc có nên đưa EIP-2537 vào nâng cấp Shanghai hay không, nhưng các nhà phát triển cho rằng EIP-2537 cần được hoãn lại, vì nâng cấp Shanghai chủ yếu hỗ trợ việc rút tiền PoS. Cuối cùng, EIP-2537 đã không được đưa vào nâng cấp Shanghai tập trung vào chức năng rút tiền.
Thậm chí còn thê thảm hơn là nâng cấp Cancun vẫn chưa thảo luận về EIP-2537, vì cốt lõi của nâng cấp Cancun là hỗ trợ EIP-4844 từ các nút lớp thực thi. EIP-4844 cung cấp Blob cho lớp hai của Ethereum để thuận tiện cho lớp hai sử dụng Ethereum làm lớp dữ liệu khả dụng.
Cuối cùng, trong cuộc họp Ethereum Core Devs Meeting #181 vào tháng 2 năm 2024, các nhà phát triển đã thảo luận về việc đưa EIP-2537 vào bản nâng cấp Pectra, và vào thời điểm này, các nhà phát triển cho rằng việc triển khai EIP-2537 không còn là vấn đề, chỉ có một số vấn đề liên quan đến cách định giá Gas tiêu thụ.
Tại cuộc họp Ethereum Core Devs vào ngày 19 tháng 12 năm 2024 #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, các nhà phát triển đã thảo luận về việc định giá lại BLS precompile, nhà phát triển Geth Jared Wasinger đã đề xuất tăng chi phí gas lên 20%, và nhận được sự hỗ trợ từ nhóm Besu trong việc kiểm tra hiệu suất.
Tóm tắt
Có thể thấy, việc EIP có được đưa vào nâng cấp Ethereum hay không "chắc chắn phải dựa vào nỗ lực tự thân, nhưng cũng cần xem xét đến hành trình lịch sử". Mỗi lần nâng cấp Ethereum đều có chủ đề riêng, giống như EIP-2537 từng là EIP quan trọng nhất trong nâng cấp Berlin, nhưng đã bị loại bỏ do độ khó và phức tạp trong việc thực hiện. Sau đó, Ethereum đã bước vào tiến trình lịch sử PoS, các EIP thuần thực thi phức tạp không được chú trọng, trong khi rất nhiều EIP thực thi liên quan đến PoS được coi là mục tiêu nâng cấp cốt lõi, điều này đã dẫn đến việc EIP-2537 không được chấp nhận trong một thời gian dài.