Nguồn chính thức:Tweet của @protolambda

Từ "Block" đến "Blob", ý nghĩa rất sâu sắc.

Từ "Block" đến "Blob", ý nghĩa rất sâu sắc.

Các "chuỗi phân đoạn" có thể thực thi với "liên kết ngang" đã bị loại bỏ: Triển khai EVM trong chuỗi đèn hiệu; lộ trình Ethereum tập trung vào quá trình cuộn bằng cách sử dụng "lấy mẫu tính khả dụng của dữ liệu", mở rộng lớp cơ sở Ethereum mà không làm tăng độ phức tạp của môi trường ứng dụng. Nhưng làm thế nào để bạn gọi nội dung phân đoạn mà không có siêu dữ liệu khối?

Chà, đây là lúc "đốm màu" có ích. "Blobspace" là một cái tên hay!

Hãy để tôi chia sẻ một số lịch sử của thiết kế Ethereum sharding:

Sharding (hoặc "Giai đoạn 1") được cho là sẽ khởi chạy trong "Giai đoạn 2" (Môi trường thực thi chuỗi Beacon) như đã lên kế hoạch trước đó. Nhưng trước "giai đoạn 0" (khởi chạy chuỗi đèn hiệu), rõ ràng là EVM của mạng chính được ưu tiên, trong khi việc triển khai lớp thực thi "giai đoạn 2" (ewasm?) vẫn chưa xuất hiện.

Thông số kỹ thuật "Giai đoạn 1" đã được viết lại nhiều lần trước Beacon Chain:

• Ít mảnh hơn (1024 -> 64)

• Đi xe miễn phí với giao tiếp giữa các phân đoạn lý tưởng (liên kết chéo)

• Thiết kế bằng chứng ký quỹ mới (loại bỏ phần ký quỹ để tránh làm mất bằng chứng cố ý hiếm gặp)

Thành thật mà nói, không đề cập đến công việc nghiên cứu sharding trước đây, những nghiên cứu đó rất trừu tượng và đầy tham vọng: chuyển thông báo giữa các miền, môi trường thực thi với ewasm, truy cập động không trạng thái, ủy ban sharding, v.v. L1 trở nên phức tạp hơn. Và L1 đã bắt đầu cốt hóa.

Tuy nhiên, nếu L1 chỉ tập trung vào việc giải quyết các vấn đề về dữ liệu, thì hầu hết các vấn đề được đề cập ở trên sẽ chuyển thành các vấn đề phát triển L2. Còn việc lấy mẫu (sampling) mới giải quyết được vấn đề dữ liệu L1. Điều gì sẽ xảy ra nếu chúng tôi có thể hỗ trợ chức năng bổ sung ở lớp mạng...?

Vì vậy, vào ngày 14 tháng 10 năm 2020, các nhà phát triển đã có một cuộc gọi hội nghị liên quan đến "Sự cố kết nối mạng (mạng) Giai đoạn 1". Sau khi thảo luận, có thể kết luận: gogsub đang rất hot + DHTs có vẻ chậm. Nhưng vào thời điểm đó, vẫn còn sớm - mọi nhà phát triển web vẫn đang bận rộn chuẩn bị cho việc ra mắt chuỗi đèn hiệu (ngày 1 tháng 12!), và do những phát triển mới nhất vào thời điểm đó, có một khoảng cách rõ ràng trong lớp mạng.

Xu hướng tại thời điểm đó:

• Gossipsub = hot, mainnet đã sẵn sàng (không có nhiều vấn đề ngoại trừ một số vấn đề DoS. Và những vấn đề này cũng đã được phát hiện/tiết lộ trước khi khởi chạy mainnet)

• Discv5 = chưa hoàn thành, cần di chuyển mạng trực tiếp từ 5.0 -> 5.1 trước khi khởi chạy mạng chính

(https://github.com/protolambda/discv5-catdog)

Nhưng hướng có vẻ rõ ràng: giảm độ phức tạp của L1, chuỗi đèn hiệu đã đủ phức tạp. Chỉ cải thiện khả năng mở rộng thông qua dữ liệu, sử dụng sơ đồ "lấy mẫu tính khả dụng của dữ liệu" trong thời gian dài và sử dụng các giải pháp mở rộng L2. Do đó, Vitalik đã mô tả nó là "Lộ trình Ethereum tập trung vào Rollup" (phiên bản tiếng Trung).

Tuy nhiên, trong khi những người triển khai bận rộn với việc phát hành chuỗi đèn hiệu, thì các nhà nghiên cứu lại bận rộn với công việc sau khi ra mắt: Vitalik/Dankrad đang làm việc trên một số bản thảo thiết kế sẵn có dữ liệu ban đầu, cố gắng làm cho các nguyên tắc dễ hiểu hơn đối với những người triển khai.

Đồng thời, chúng tôi đã khởi chạy mạng thử nghiệm Zinken, Toledo và Pyrmont + kiểm tra thêm các mục khởi chạy (kiểm tra lỗi, v.v.). Và chúng tôi cố gắng theo kịp nghiên cứu và bắt đầu thêm tài liệu thiết kế cho những thứ trên lớp mạng. Vào thời điểm đó, còn quá sớm để tập trung vào những vấn đề này, nhưng DAS (Lấy mẫu sẵn có của dữ liệu) quá tốt để bỏ qua.

Dựa trên một số nội dung từ Goolgesub, tôi đã viết một số ý tưởng để sử dụng nó cho DAS. Nhìn nhận lại, bây giờ tôi nghĩ rằng DHT phù hợp với DAS hơn Gossipsub, có lẽ ngoại trừ việc phân phối ban đầu.

Vào thời điểm đó, tôi mong đợi một số thông số kỹ thuật DAS sẽ được triển khai và mô phỏng. Tôi nghĩ đây là lần đầu tiên "blob" được đề cập? Chúng tôi đã sử dụng nó trong các ngữ cảnh như "các đốm màu dữ liệu được phân mảnh" và thuật ngữ đó không xuất hiện trong thông số kỹ thuật cho phân mảnh sau đó.

Sau khi chuỗi đèn hiệu được phát hành, tôi có nhiều thời gian hơn và sau đó tôi đã viết một bản nháp bổ sung thêm nội dung lớp mạng và đánh máy vào bản nháp thông số kỹ thuật lấy mẫu do Vitalik và Dankrad viết. Đưa cách đặt tên blob vào đặc điểm kỹ thuật của các phân đoạn :)

Một số điều đã thay đổi vào năm 2021: cấu trúc p2p lý tưởng được thiết kế cho nó quá phức tạp, vì vậy, thay vào đó, tôi đã thử đóng góp các công cụ cho nó (go-kzg) và tham gia vào các nỗ lực hợp nhất sớm (rayonism). Sau đó, hãy thử lại vào mùa hè để tham gia công việc nghiên cứu về sharding thay vì phát triển bản nâng cấp Altair/London.

Các đốm màu lại xuất hiện, lần này với cấu trúc giống PBS hơn - tổng hợp các chữ ký BLS của trình tạo blob và trình đề xuất blob. Vẫn còn quá phức tạp: do đó, thiết kế sharding đã phát triển chủ yếu là "lấy người đề xuất đèn hiệu làm trung tâm", sao cho nó "chỉ" là một vấn đề ở tầng mạng.

Theo một cách nào đó, đây giống như một thiết kế thứ năm để phân mảnh? Chủ nghĩa tối giản nghĩa là từ bỏ rất nhiều thứ, nhưng kết quả lại rất đẹp và mạnh mẽ: thiết kế kiểu mô-đun, bao bì và độ phức tạp tùy chọn nhiều hơn. Rollup thu hút sự chú ý của tôi, đặc biệt là Chủ nghĩa lạc quan.

Cuối năm 2022, EIP 4488 (đừng nhầm lẫn, không phải 4844!) và 4490: Mọi người bắt đầu mất kiên nhẫn và chi phí dữ liệu cuộc gọi phải giảm nhanh để duy trì tính cạnh tranh! Các cuộc thảo luận về những chủ đề này cũng trở nên sôi nổi tại All Core devs sau khi nâng cấp ở London. Nhưng theo tôi, điều này là không bền vững vì calldata đi kèm với chi phí kế thừa mà L2 không cần.

Trong khi đó, Vitalik và Dankrad tiếp tục nghiên cứu một số thiết kế sharding mới: tập trung vào chuỗi đèn hiệu hơn, chỉ mở rộng quy mô thông qua dữ liệu và tập trung vào các kế hoạch lấy mẫu. Tôi nghĩ "danksharding" thực sự ra mắt vào cuối ngày 21/đầu ngày 22? Không chắc phiên bản đầu tiên là gì, Dankrad đã nghiên cứu về sharding.

Vào đầu năm 22, Vitalik đã đề xuất hai cách mà chúng tôi có thể phát triển theo hướng darksharding hoàn toàn mà không cần sử dụng lấy mẫu: một phiên bản đơn giản và một phiên bản phức tạp. Mặc dù theo ý kiến ​​​​của tôi, đây thực sự là sự khác biệt giữa "EL nặng (lớp thực thi)" và "tách EL và CL để tương thích dễ dàng hơn và trong tương lai".

Tôi thích tùy chọn thứ hai và sau đó trong EthDenver 2022, chúng tôi đã triển khai EIP-4844: tôi và @lightclients làm việc trên Geth; @asn_d6 trợ giúp với KZG; @adietrichs làm việc trên thị trường tính phí; và cả hai cùng Vitalik/Dankrad Soạn thảo một EIP. Nhóm Prysm đã chế tạo nguyên mẫu CL đầu tiên.

4844 bây giờ được đặt tên"proto-danksharding": Điều kiện tiên quyết để đạt được sharding hoàn chỉnh. Nhưng "blobspace" mới là meme thực sự: sau nhiều lần lặp lại thiết kế sharding, đây là phiên bản gần với tầm nhìn của Ethereum hơn bất kỳ thiết kế sharding nào khác.

Đối với tôi, giai đoạn này của Serenity là tất cả về PoS, thiết kế phân đoạn và các bản cập nhật lặp đi lặp lại. Chúng tôi đã đạt được một số tiến bộ trên beacon chain và các phát triển như PBS ngoài giao thức, giúp chúng tôi có một khởi đầu thuận lợi trên PoS. Tôi nghĩ đã đến lúc nâng cấp phân đoạn đầu tiên: 4844!

Ngoài ra còn có một số điểm nóng cho darksharding trong tương lai:

• Tác động của độ trễ bao gồm dữ liệu L1 đối với L2 được đánh giá quá cao.

• Sự đánh đổi không gian thiết kế đáng giá để có thêm băng thông cho tính khả dụng của dữ liệu.

• Tin đồn và TCP DHT không tốt, phạm vi phủ sóng của lớp UDP DHT tốt: tất cả là về việc đếm các nút nhẹ (khi nào discv5 mở rộng quy mô?)

Thêm các điểm nóng của danksharding:

• Việc lấy mẫu chủ yếu dựa vào các đồng nghiệp tốt, muốn xem nhiều thiết kế có điểm số đầu tiên nhưng mạnh mẽ hơn.

• Thích giao tiếp nhẹ nhàng và nhiều Sybil hơn là thiếu quyền riêng tư của trình xác thực hơn p2p.

• ZK có thể trở thành công nghệ chống phù thủy p2p trong tương lai, nhưng có vẻ như nó còn rất xa.