Delphi Digital: Hiểu biết toàn diện về lộ trình bảo vệ Ethereum
Tựa gốc: "Hướng dẫn về Ethereum của người đi nhờ xe"
Tác giả gốc: Delphi Digital
Bản tổng hợp gốc: Con đường của DeFi
Những điểm chính
Ethereum là giao thức chính duy nhất xây dựng lớp sẵn sàng dữ liệu và thanh toán thống nhất có thể mở rộng
Tập hợp quy mô điện toán đồng thời tận dụng tính bảo mật của Ethereum
Mọi con đường đều dẫn đến sự kết thúc của việc sản xuất khối tập trung, xác minh khối không cần sự tin cậy phi tập trung và khả năng chống kiểm duyệt
Những đổi mới như sự tách biệt giữa người đề xuất và người xây dựng và tình trạng không quốc tịch yếu sẽ mở khóa sự phân chia quyền lực này (xây dựng và xác minh) để cho phép khả năng mở rộng mà không làm mất đi tính bảo mật hoặc phân cấp
MEV hiện là trung tâm - những nỗ lực thiết kế sâu rộng được lên kế hoạch để giảm thiểu tác hại và ngăn chặn xu hướng tập trung hóa của nó
Danksharding kết hợp nhiều hướng nghiên cứu tiên tiến để cung cấp lớp cơ sở có thể mở rộng cần thiết cho lộ trình tập trung vào Rollup của Ethereum
Tôi thực sự hy vọng sẽ đạt được điều đó trong cuộc đời của chúng ta
Giới thiệu
Tôi đã nghi ngờ về dòng thời gian của The Merge kể từ khi Vitalik nói rằng ai đó sinh ra vào ngày hôm nay có 50-75% cơ hội sống đến năm 3000 và anh ta mong muốn được bất tử. Tuy nhiên, hãy coi đây là một trò đùa, dù thế nào đi nữa, chúng ta vẫn phải hướng tới lộ trình đầy tham vọng của Ethereum.
Đây không phải là một bài đọc nhanh. Nếu bạn muốn có sự hiểu biết sâu rộng và sâu sắc về lộ trình đầy tham vọng của Ethereum – hãy dành cho tôi một giờ chú ý và tôi sẽ giúp bạn tiết kiệm được nhiều tháng làm việc.
Có nhiều hướng nghiên cứu về Ethereum cần được theo dõi trong thời gian dài, nhưng cuối cùng mọi thứ đều hướng đến một mục tiêu bao quát - mở rộng quy mô tính toán mà không phải hy sinh quá trình xác minh phi tập trung.
Tôi hy vọng bạn đã quen thuộc với bài viết "End Game" nổi tiếng của Vitalik. Trong bài báo, ông thừa nhận rằng cần phải có sự tập trung nhất định để đạt được quy mô. Từ bắt đầu bằng chữ "C" này rất đáng sợ trong blockchain, nhưng đó là sự thật. Chúng ta chỉ cần duy trì sức mạnh này thông qua xác minh phi tập trung và không cần sự tin cậy. Không có sự thỏa hiệp ở đây.
Chuyên gia sẽ xây dựng module từ L1 trở lên. Ethereum vẫn rất an toàn với xác minh phi tập trung đơn giản và Rollup kế thừa tính bảo mật của họ từ L1. Ethereum sau đó cung cấp khả năng thanh toán và tính khả dụng của dữ liệu, cho phép Rollup mở rộng quy mô. Tất cả các nghiên cứu ở đây cuối cùng đều hy vọng tối ưu hóa hai vai trò này đồng thời giúp việc xác minh đầy đủ chuỗi trở nên dễ dàng hơn bao giờ hết.
Đây là bảng thuật ngữ viết tắt một số từ sẽ xuất hiện ~43531756765713534 lần:
DA – Tính sẵn có của dữ liệu
DAS – Lấy mẫu dữ liệu sẵn có
PBS–Tách biệt người đề xuất-người xây dựng
PDS–sharding gốc
DS–Danksharding
PoW——Bằng chứng công việc
PoS – Bằng chứng cổ phần
Phần I: Con đường đến Danksharding
Hy vọng rằng bạn đã biết rằng Ethereum đã chuyển sang lộ trình tập trung vào Rollup. Không còn phân đoạn thực thi nữa – Thay vào đó, Ethereum sẽ được tối ưu hóa cho các Bản tổng hợp ngốn nhiều dữ liệu. Điều này đạt được thông qua việc phân chia dữ liệu (kế hoạch của Ethereum) hoặc các khối lớn (kế hoạch của Celestia).
Lớp đồng thuận không diễn giải dữ liệu được phân chia. Nó có một công việc phải làm - đảm bảo dữ liệu có sẵn.
Tôi cho rằng bạn đã quen thuộc với một số khái niệm cơ bản như tổng hợp, gian lận và bằng chứng ZK cũng như lý do tại sao DA lại quan trọng. Nếu bạn chưa quen hoặc chỉ cần ôn lại, báo cáo gần đây của Can về Celestia sẽ đề cập đến tất cả.
Thiết kế sharding gốc - người đề xuất sharding độc lập
Thiết kế được mô tả ở đây không được dùng nữa nhưng đây là một kịch bản có giá trị. Để đơn giản, tôi sẽ gọi nó là “Sharding 1.0”.
Mỗi khối trong số 64 khối phân đoạn đều có những người đề xuất và ủy ban độc lập, luân phiên từ nhóm người xác thực. Họ xác minh độc lập rằng dữ liệu phân đoạn của họ có sẵn. Ban đầu đây không phải là DAS - nó dựa vào phần lớn bộ xác thực của từng phân đoạn để tải xuống đầy đủ dữ liệu.
Thiết kế này gây ra sự phức tạp không cần thiết, trải nghiệm người dùng kém hơn và các vectơ tấn công. Việc xáo trộn trình xác nhận giữa các phân đoạn là một việc khó khăn.
Trừ khi bạn đưa ra các giả định đồng bộ hóa rất nghiêm ngặt, rất khó để đảm bảo rằng việc bỏ phiếu sẽ hoàn tất trong một vị trí duy nhất. Những người đề xuất khối Beacon cần thu thập phiếu bầu từ tất cả các ủy ban riêng lẻ và có thể xảy ra sự chậm trễ.
DS hoàn toàn khác. Người xác thực thực thi DAS để xác nhận rằng tất cả dữ liệu đều có sẵn (không còn ủy ban phân đoạn riêng biệt nào nữa). Một nhà xây dựng chuyên biệt tạo ra một khối lớn với khối báo hiệu và tất cả dữ liệu phân đoạn được xác nhận cùng nhau. Do đó, PBS là cần thiết để DS duy trì tính phi tập trung (việc xây dựng các khối lớn cùng nhau sẽ tốn nhiều tài nguyên).
Lấy mẫu dữ liệu sẵn có
Bản tổng hợp xuất bản nhiều dữ liệu nhưng chúng tôi không muốn các nút tải xuống tất cả dữ liệu đó. Điều này có nghĩa là yêu cầu nguồn lực cao, ảnh hưởng đến sự phân cấp.
Ngược lại, DAS cho phép các nút (kể cả các máy khách nhẹ) xác minh một cách dễ dàng và an toàn rằng mọi thứ đều có sẵn mà không cần tải xuống mọi thứ.
- Giải pháp đơn giản - chỉ cần kiểm tra khối xem có nhiều đoạn ngẫu nhiên không. Nếu tất cả họ đều ký thì tôi cũng ký. Nhưng điều gì sẽ xảy ra nếu bạn bỏ lỡ một giao dịch đã chuyển toàn bộ ETH của bạn cho Sifu? Nguồn vốn không còn an toàn nữa.
- Giải pháp thông minh – xóa sạch dữ liệu trước. Mở rộng dữ liệu bằng mã Reed-Solomon. Điều này có nghĩa là dữ liệu được nội suy thành đa thức, sau đó chúng tôi đánh giá ở nhiều nơi khác. Đây là tất cả trong một phần, vì vậy hãy chia nhỏ nó ra.
Đối với những người gặp khó khăn trong việc hiểu toán, hãy giải thích nhanh. (Tôi hứa đây sẽ không phải là một bài toán thực sự đáng sợ - tôi đã phải xem một số video của Khan Academy để viết những phần này, nhưng giờ tôi đã hiểu rồi).
Đa thức là một biểu thức tính tổng bất kỳ số hữu hạn số hạng nào có dạng cxk. Bằng cấp là số mũ cao nhất. Ví dụ, 2 x3+6 x2+2 x-4 là đa thức bậc ba. Bạn có thể xây dựng lại bất kỳ đa thức bậc d nào từ tọa độ d+1 bất kỳ nằm trên đa thức đó.
Bây giờ hãy đưa ra một ví dụ cụ thể. Bên dưới chúng tôi có bốn khối dữ liệu (d0 đến d3). Những khối dữ liệu này có thể được ánh xạ tới việc đánh giá đa thức f (X) tại một điểm nhất định. Ví dụ: f (0) = d0. Bây giờ bạn tìm thấy đa thức bậc tối thiểu trải qua các đánh giá này. Vì đây là bốn phần nên chúng ta có thể tìm được đa thức bậc ba. Sau đó, chúng tôi có thể mở rộng dữ liệu này để thêm bốn đánh giá dọc theo cùng một đa thức (e0 đến e3).
Hãy nhớ thuộc tính đa thức quan trọng - chúng ta có thể xây dựng lại thuộc tính đó từ bốn điểm bất kỳ, không chỉ bốn khối dữ liệu ban đầu.
Quay lại DAS của chúng tôi. Bây giờ chúng ta chỉ cần đảm bảo rằng có sẵn 50% (4/8) dữ liệu được mã hóa xóa. Từ đó, chúng ta có thể xây dựng lại toàn bộ khối.
Do đó, kẻ tấn công sẽ phải ẩn hơn 50% khối để lừa thành công các nút DAS nghĩ rằng dữ liệu có sẵn trong khi thực tế không có.
Sau nhiều mẫu ngẫu nhiên thành công, <50% là xác suất rất nhỏ. Nếu chúng tôi lấy mẫu thành công dữ liệu được mã hóa xóa 30 lần thì xác suất có thể sử dụng được <50% là 2-30.
Cam kết của KZG
Được rồi, chúng tôi đã tạo một loạt mẫu ngẫu nhiên và tất cả đều có sẵn. Nhưng chúng tôi có một câu hỏi khác - mã hóa xóa dữ liệu có đúng không? Mặt khác, có thể các nhà sản xuất khối chỉ thêm 50% rác khi mở rộng khối và chúng tôi đã lấy mẫu rác. Trong trường hợp này, chúng tôi thực sự không thể xây dựng lại dữ liệu.
Thông thường, chúng tôi gửi lượng lớn dữ liệu chỉ bằng cách sử dụng gốc Merkle. Điều này có hiệu quả để chứng minh rằng một tập hợp có chứa dữ liệu nhất định.
Tuy nhiên, chúng ta cũng cần biết rằng tất cả dữ liệu gốc và dữ liệu mở rộng đều nằm trên cùng một đa thức bậc thấp. Rễ Merkle không chứng minh điều này. Vì vậy, nếu bạn sử dụng chương trình này, bạn cũng sẽ cần bằng chứng gian lận, đề phòng trường hợp có điều gì đó sai trái.
Các nhà phát triển đang làm việc theo hai hướng:
- Celestia đang đi theo con đường ngăn chặn gian lận. Ai đó cần lưu ý rằng nếu một khối bị xóa mã không chính xác, họ sẽ gửi bằng chứng gian lận để cảnh báo cho mọi người. Điều này đòi hỏi giả định thiểu số trung thực tiêu chuẩn và giả định đồng bộ hóa (tức là, ngoài việc ai đó gửi cho tôi bằng chứng gian lận, tôi cũng cần giả định rằng tôi đã kết nối và sẽ nhận được nó trong một khoảng thời gian giới hạn).
- Ethereum và Polygon Avail đang đi theo một lộ trình mới - Cam kết KZG (còn gọi là Cam kết Kate). Điều này loại bỏ các giả định về bảo mật đồng bộ hóa và thiểu số trung thực liên quan đến bằng chứng gian lận (mặc dù chúng vẫn ở đó để tái thiết, chúng tôi sẽ đề cập ngay sau đây).
Có các giải pháp khác nhưng không được tích cực theo đuổi. Ví dụ: bạn có thể sử dụng bằng chứng ZK. Thật không may, chúng (chưa) về mặt tính toán là không thực tế. Tuy nhiên, chúng dự kiến sẽ cải thiện trong những năm tới, vì vậy Ethereum có thể chuyển sang STARK trong tương lai vì KZG hứa hẹn sẽ không có khả năng kháng lượng tử.
Quay lại cam kết KZG - đây là sơ đồ cam kết đa thức.
Lược đồ cam kết chỉ đơn giản là một cách mã hóa để chứng minh cam kết đối với một số giá trị. Phép ẩn dụ hay nhất là bỏ một lá thư vào một chiếc hộp có khóa và đưa nó cho người khác. Bức thư không thể thay đổi một khi đã vào bên trong, nhưng nó có thể được mở bằng chìa khóa và đã được chứng minh. Cái mới bạn nộp là lời hứa, mấu chốt là bằng chứng.
Trong trường hợp của chúng tôi, chúng tôi ánh xạ tất cả dữ liệu gốc và dữ liệu mở rộng vào lưới X, Y, sau đó tìm đa thức bậc tối thiểu đi qua chúng (quá trình này được gọi là nội suy Lagrange). Đa thức này là điều mà người chứng minh sẽ cam kết:
Sau đây là những điểm chính:
- Ta có "đa thức" f(X)
- Người chứng minh đưa ra “cam kết” với đa thức C(f)
Điều này dựa vào mật mã đường cong elip với các cài đặt đáng tin cậy. Để biết thêm chi tiết về cách thức hoạt động của tính năng này, hãy xem bài đăng tuyệt vời của Bartek
Đối với bất kỳ "đánh giá" nào về đa thức y = f (z), người chứng minh có thể tính "bằng chứng" π(f,z)
Với cam kết C (f), bằng chứng π(f,z), bất kỳ vị trí z nào và đánh giá y của đa thức tại z, người xác minh có thể xác nhận rằng thực sự f (z) = y
Giải thích: Người chứng minh cung cấp các đoạn này cho bất kỳ người xác minh nào, người sau đó có thể xác nhận rằng việc đánh giá một điểm (trong đó đánh giá thể hiện dữ liệu cơ bản) nằm chính xác trên đa thức đã cam kết
Điều này chứng tỏ rằng dữ liệu gốc được mở rộng một cách chính xác, vì tất cả các đánh giá đều nằm trên cùng một đa thức
Lưu ý rằng, Trình xác minh không yêu cầu đa thức f(X)
Thuộc tính quan trọng - thuộc tính này có kích thước cam kết O(1), kích thước bằng chứng O(1) và thời gian xác minh O(1). Ngay cả đối với người chứng minh, cam kết và tạo bằng chứng chỉ có thang đo theo O(d), trong đó d là bậc của đa thức
Giải thích: Ngay cả khi n (số lượng giá trị thay đổi về kích thước và việc xác minh đòi hỏi nỗ lực liên tục
Cả cam kết C (f) và bằng chứng (f,z) chỉ là một phần tử đường cong elip trên đường cong thân thiện với ghép nối (Điều này sẽ sử dụng BL12-381). Trong trường hợp này, chúng chỉ có 48 byte mỗi cái (rất nhỏ)
Do đó, người chứng minh gửi một lượng lớn dữ liệu thô và dữ liệu mở rộng (đại diện cho bội số đa thức đánh giá) vẫn chỉ có 48 byte, bằng chứng cũng chỉ có 48 byte
TLDR – điều này có khả năng mở rộng cao
Sau đó, các nghiệm KZG (các cam kết đa thức) tương tự như các nghiệm thức Merkle (là các cam kết vectơ):
Dữ liệu gốc nằm ở vị trí f (0) đến f (3) Tính đa thức f (X), sau đó chúng tôi mở rộng nó bằng cách tính đa thức từ f (4) đến f (7). Tất cả các điểm f(0) đến f(7) được đảm bảo nằm trên cùng một đa thức.
Tóm lại: DAS cho phép chúng tôi kiểm tra xem dữ liệu được mã hóa xóa có sẵn hay không. Cam kết của KZG chứng minh cho chúng tôi thấy rằng dữ liệu gốc được chia tỷ lệ hợp lý và hứa hẹn tất cả những điều này.
Làm tốt lắm, đó là bài đại số hôm nay.
Cam kết của KZG và Bằng chứng gian lận
Bây giờ chúng tôi đã hiểu cách hoạt động của KZG, vui lòng quay lại The bước sau so sánh hai phương pháp.
Nhược điểm của KZG - nó không an toàn sau lượng tử và yêu cầu thiết lập đáng tin cậy. Những điều này không đáng lo ngại. STARK cung cấp giải pháp thay thế hậu lượng tử với thiết lập đáng tin cậy (sự tham gia mở) chỉ yêu cầu một người tham gia trung thực.
Ưu điểm của KZG - độ trễ thấp hơn so với thiết lập bằng chứng gian lận (mặc dù như đã đề cập, GASPER dù sao cũng không có tính xác định nhanh) và đảm bảo mã hóa xóa thích hợp mà không cần đưa vào giả định thiểu số về tính đồng bộ hóa và tính trung thực vốn có trong bằng chứng gian lận.
Tuy nhiên, do Ethereum vẫn đưa ra lại các giả định này cho việc tái thiết khối nên bạn không thực sự loại bỏ chúng. Lớp DA luôn cần lập kế hoạch cho kịch bản ban đầu khối được cung cấp, nhưng sau đó các nút cần liên lạc với nhau để đặt khối lại với nhau. Việc tái cấu trúc này yêu cầu hai giả định:
Bạn có đủ nút (nút nhẹ hoặc nút đầy đủ) để lấy mẫu dữ liệu sao cho đủ để kết hợp lại chúng với nhau. Đây là một giả định thiểu số trung thực khá yếu và không thể tránh khỏi nên không phải là vấn đề lớn.
Giới thiệu lại giả định đồng bộ hóa - các nút cần có khả năng giao tiếp trong một khoảng thời gian trước khi chúng có thể được đặt lại với nhau.
Người xác thực Ethereum tải xuống đầy đủ blob phân đoạn trong PDS và với DS, họ sẽ chỉ thực hiện DAS (tải xuống các hàng và cột được phân bổ). Celestia sẽ yêu cầu người xác thực tải xuống toàn bộ khối.
Lưu ý rằng trong cả hai trường hợp, chúng ta đều cần các giả định về đồng bộ hóa để tái thiết. Nếu khối chỉ khả dụng một phần, nút đầy đủ phải liên lạc với các nút khác để ghép nó lại với nhau.
Nếu Celestia chuyển từ yêu cầu người xác thực tải xuống tất cả dữ liệu sang chỉ thực thi DAS (mặc dù việc chuyển đổi như vậy hiện chưa được lên kế hoạch), thì lợi thế về độ trễ của KZG sẽ rõ ràng.
Sau đó, họ cũng cần thực hiện các cam kết của KZG - chờ đợi bằng chứng gian lận có nghĩa là tăng đáng kể khoảng thời gian chặn và người xác thực bỏ phiếu cho các khối được mã hóa không chính xác. Tiền đặt cược sẽ rất cao.
Tôi đề xuất những điều sau để tìm hiểu sâu hơn về cách thức hoạt động của các cam kết KZG:
Oval A (tương đối dễ hiểu) giới thiệu về mật mã đường cong
Khám phá cặp đường cong Elliptic – Vitalik
Cam kết đa thức KZG – Dakrad
Thiết lập đáng tin cậy hoạt động như thế nào? – Vitalik
Sự tách biệt giữa người đề xuất và người xây dựng giao thức nội bộ
Các nút đồng thuận ngày nay (công cụ khai thác) và người được hợp nhất (người xác minh) đóng hai vai trò. Họ xây dựng khối thực tế và sau đó đề xuất nó cho các nút đồng thuận khác để xác nhận nó. Người khai thác "bỏ phiếu" trên cơ sở khối trước đó, sau khi hợp nhất, người xác nhận sẽ trực tiếp bỏ phiếu xem khối đó hợp lệ hay không hợp lệ.
PBS tách biệt chúng - nó rõ ràng tạo ra vai trò xây dựng giao thức nội bộ mới. Các nhà xây dựng chuyên nghiệp sẽ ghép các khối lại với nhau và những người đề xuất giá thầu (người xác thực) sẽ chọn các khối của họ. Điều này chống lại sức mạnh tập trung của MEV.
Hãy nhớ lại bài viết “Endgame” của Vitalik – mọi con đường đều dẫn đến sản xuất khối tập trung, với xác minh phi tập trung và không cần tin cậy. PBS đã biên soạn cái này. Chúng tôi cần một người xây dựng trung thực để phục vụ mạng nhằm đảm bảo tính sống động và khả năng chống kiểm duyệt (cần có hai yếu tố để thị trường hiệu quả), nhưng bộ trình xác thực yêu cầu đa số trung thực. PBS làm cho vai trò của người đề xuất trở nên đơn giản nhất có thể để hỗ trợ việc phân quyền cho người xác thực.
Các nhà xây dựng nhận được các khoản phí ưu tiên cộng với bất kỳ MEV nào họ có thể rút. Trong một thị trường hiệu quả, các nhà xây dựng cạnh tranh sẽ đặt giá thầu cho toàn bộ giá trị mà họ có thể trích xuất từ một khối (trừ chi phí khấu hao của họ, chẳng hạn như phần cứng mạnh mẽ, v.v.). Tất cả giá trị đều thấm vào bộ trình xác thực phi tập trung - chính xác là những gì chúng tôi muốn.
Việc triển khai PBS chính xác vẫn đang được thảo luận, nhưng PBS hai khe có thể trông như thế này:
- Nhà xây dựng sử dụng Khối khu vực cam kết giá thầu của họ tiêu đề
- Người đề xuất khối báo hiệu chọn tiêu đề và giá thầu của khối chiến thắng. Kể cả trường hợp nhà thầu không sản xuất được phần thân thì người đấu giá vẫn được trúng thầu vô điều kiện
- Hội đồng chứng nhận xác nhận phần thân trúng thầu
- Nhà thầu công bố phần thân trúng thầu
- Một ủy ban độc lập gồm những người chứng thực bầu ra cơ quan thắng cuộc (nếu người thắng cuộc không đồng ý, họ bỏ phiếu vắng mặt)
Người đề xuất được bầu sử dụng RANDAO tiêu chuẩn Cơ chế được chọn từ bộ trình xác nhận. Sau đó, chúng tôi sử dụng sơ đồ tiết lộ cam kết trong đó toàn bộ nội dung khối không được tiết lộ cho đến khi ủy ban xác nhận tiêu đề khối.
tiết lộ cam kết hiệu quả hơn (gửi xung quanh hàng trăm khối đầy đủ có thể áp đảo băng thông của lớp p2 p) và nó cũng ngăn chặn hành vi trộm MEV. Nếu một người xây dựng gửi toàn bộ khối của họ, một người xây dựng khác có thể nhìn thấy nó, tìm ra chiến lược đó, hợp nhất nó và nhanh chóng xuất bản một khối tốt hơn. Ngoài ra, những người đề xuất trưởng thành có thể phát hiện chiến lược MEV đang được sử dụng và nhân rộng nó mà không phải bồi thường cho người xây dựng. Nếu việc đánh cắp MEV này trở thành một sự cân bằng, nó sẽ khuyến khích những người xây dựng và đề xuất hợp nhất, vì vậy chúng tôi sử dụng cam kết tiết lộ để tránh điều này.
Sau khi người đề xuất chọn tiêu đề khối chiến thắng, ủy ban sẽ xác nhận và sửa đổi các quy tắc lựa chọn ngã ba. Sau đó, người xây dựng chiến thắng sẽ xuất bản nội dung "khối xây dựng" hoàn chỉnh chiến thắng của họ. Nếu được trả tự do kịp thời, lời khai sẽ được đưa ra cho ủy ban tiếp theo. Nếu không công bố kịp thời, họ vẫn phải trả toàn bộ giá thầu cho người đề xuất (và mất toàn bộ MEV và phí). Khoản thanh toán vô điều kiện này giúp người đề xuất không cần phải tin tưởng vào người xây dựng.
Nhược điểm của thiết kế "hai khe" này là độ trễ. Khối được hợp nhất sẽ có thời gian cố định là 12 giây, vì vậy nếu chúng tôi không muốn đưa ra bất kỳ giả định mới nào, ở đây chúng tôi cần 24 giây để có thời gian khối đầy đủ (hai khe 12 giây). 8 giây cho mỗi vị trí (thời gian khối 16 giây) dường như là một sự thỏa hiệp an toàn, mặc dù nghiên cứu vẫn đang tiếp tục.
Danh sách chống kiểm duyệt (crList)
Thật không may, PBS cung cấp cho các nhà xây dựng nhiều khả năng xem xét cao hơn giao dịch. Có thể người xây dựng không thích bạn nên họ bỏ qua thỏa thuận của bạn. Có thể họ làm việc giỏi đến mức tất cả những người xây dựng khác đều bỏ cuộc, hoặc họ chỉ trả giá quá cao cho các khối vì họ thực sự không thích bạn.
crLists đã kiểm tra khả năng này. Việc triển khai chính xác lại là một không gian thiết kế mở, nhưng "PBS lai" dường như là phổ biến nhất. Người đề xuất chỉ định danh sách tất cả các giao dịch đủ điều kiện mà họ thấy trong mempool và người xây dựng buộc phải đưa chúng vào (trừ khi khối đã đầy):
Người đề xuất xuất bản một crList và một bản tóm tắt crList bao gồm tất cả các Giao dịch có điều kiện
Các nhà xây dựng tạo ra phần thân khối được đề xuất và sau đó gửi giá thầu bao gồm hàm băm của thông báo crList, chứng minh rằng họ đã nhìn thấy nó
Người đề xuất chấp nhận giá thầu của người xây dựng chiến thắng và tiêu đề khối (họ chưa nhìn thấy nội dung)
Người chứng minh kiểm tra tính hợp lệ của nội dung đã xuất bản
Vẫn còn những vấn đề quan trọng cần giải quyết ở đây. Ví dụ, chiến lược kinh tế chủ đạo ở đây là yêu cầu những người đề xuất đưa ra một danh sách trống. Ngay cả người xây dựng đánh giá cũng có thể thắng cuộc đấu giá miễn là đặt giá thầu cao nhất. Có một số ý tưởng để giải quyết vấn đề này và các vấn đề khác, nhưng chỉ cần nhấn mạnh rằng thiết kế ở đây không cố định.
Lược đồ KZG 2D
Chúng tôi đã thấy các cam kết KZG cho phép chúng tôi cam kết dữ liệu và chứng minh rằng dữ liệu được chia tỷ lệ chính xác như thế nào. Tuy nhiên, tôi đã đơn giản hóa hoạt động thực tế của Ethereum. Nó không cam kết tất cả dữ liệu trong một cam kết KZG duy nhất - một khối duy nhất sẽ sử dụng nhiều cam kết KZG.
Chúng ta đã có một người xây dựng chuyên dụng, vậy tại sao không để họ tạo ra một cam kết KZG khổng lồ? Vấn đề là việc này đòi hỏi một siêu nút mạnh mẽ để xây dựng lại. Chúng ta có thể chấp nhận các yêu cầu về siêu nút cho quá trình xây dựng ban đầu, nhưng chúng ta cần tránh giả định về việc xây dựng lại ở đây. Chúng tôi cần một thực thể có ít nguồn lực hơn để xử lý việc xây dựng lại và việc chia nó thành nhiều cam kết KZG sẽ giúp điều này trở nên khả thi. Với lượng dữ liệu có trong tay, việc tái thiết thậm chí có thể khá phổ biến hoặc giả định trường hợp cơ bản trong thiết kế này.
Để xây dựng lại dễ dàng hơn, mỗi khối sẽ chứa m đốm màu được mã hóa trong m cam kết KZG. Làm điều này một cách ngây thơ sẽ dẫn đến rất nhiều mẫu - bạn sẽ thực thi DAS trên mỗi blob phân đoạn để biết rằng tất cả đều có sẵn (m*k mẫu, trong đó k là số lượng mẫu trên mỗi blob).
Thay vào đó, Ethereum sẽ sử dụng sơ đồ KZG 2D. Chúng tôi lại sử dụng bộ luật Reed-Solomon để mở rộng m cam kết lên 2 m cam kết:
Chúng tôi biến nó thành sơ đồ 2D bằng cách mở rộng nó với một cam kết KZG bổ sung (ở đây là 256-511) nằm trên cùng một đa thức với 0- 255 . Bây giờ chúng ta chỉ cần DAS bảng trên để đảm bảo tính khả dụng của dữ liệu cho tất cả các phân đoạn.
Yêu cầu lấy mẫu 2D là 75% dữ liệu có sẵn (so với 50% trước đó) có nghĩa là chúng tôi thực hiện số lượng mẫu cố định lớn hơn một chút. Trước đây tôi đã đề cập đến 30 mẫu cho DAS theo sơ đồ một chiều đơn giản, nhưng điều này sẽ yêu cầu 75 mẫu để đảm bảo cơ hội xác suất tương tự để xây dựng lại một khối có thể sử dụng được.
Sharding 1.0 (với sơ đồ cam kết KZG một chiều) chỉ yêu cầu 30 mẫu, nhưng muốn kiểm tra toàn bộ DA của 1920 mẫu thì cần phải Slices được lấy mẫu. Mỗi mẫu là 512 B nên điều này yêu cầu:
(512 B x 64 ô x 30 mẫu)/16 giây = băng thông 60 KB/s
Hiệu quả , trình xác nhận chỉ được xáo trộn mà không kiểm tra tất cả các phân đoạn riêng lẻ.
Các khối kết hợp sử dụng sơ đồ cam kết 2D KZG giờ đây khiến việc kiểm tra DA đầy đủ trở nên đơn giản. Nó chỉ yêu cầu 75 mẫu của một khối thống nhất:
(512 B x 1 khối x 75 mẫu)/16 giây = băng thông 2,5 KB/s
Danksharding
PBS ban đầu được thiết kế để làm suy yếu sự tập trung của MEV vào bộ trình xác thực . Tuy nhiên, Dankrad gần đây đã tận dụng thiết kế này và nhận ra rằng nó đã mở khóa được một cấu trúc sharding tốt hơn - DS.
DS tận dụng các nhà xây dựng chuyên dụng để tạo ra một chuỗi đèn hiệu thực hiện tích hợp chặt chẽ hơn các khối và phân đoạn. Bây giờ chúng tôi có một người xây dựng, một người đề xuất và một ủy ban cùng nhau tạo ra toàn bộ khối. DS sẽ không khả thi nếu không có PBS - trình xác thực thông thường không thể xử lý băng thông khổng lồ của các khối chứa đầy các đốm dữ liệu cuộn lên:
Shard 1.0 bao gồm 64 ủy ban độc lập và những người đề xuất, vì vậy mỗi Máy tính bảng phân đoạn có thể không có sẵn riêng lẻ. Tích hợp chặt chẽ hơn ở đây cho phép chúng tôi bảo mật DA chỉ trong một lần. Dữ liệu vẫn được "phân mảnh" ở hậu trường, nhưng từ góc độ thực tế, danksharding đang bắt đầu có cảm giác giống như những khối lớn hơn, điều này thật tuyệt.
Danksharding – Xác minh đa số trung thực
Dữ liệu bằng chứng của người xác thực có sẵn như sau:
Điều này phụ thuộc vào phần lớn những người xác thực trung thực — —Là một trình xác thực duy nhất, các cột và hàng của tôi có sẵn không đủ để mang lại cho tôi sự tin cậy về mặt thống kê rằng toàn bộ khối đều có sẵn. Nó phụ thuộc vào việc đa số người trung thực nói nó như thế nào. Xác minh phi tập trung là quan trọng.
Lưu ý rằng điều này khác với 75 mẫu ngẫu nhiên mà chúng ta đã thảo luận trước đó. Lấy mẫu ngẫu nhiên riêng tư là một cách để những cá nhân nghèo tài nguyên dễ dàng kiểm tra tính khả dụng (ví dụ: tôi có thể chạy nút ánh sáng DAS và biết rằng khối đó có sẵn). Tuy nhiên, người xác thực sẽ tiếp tục sử dụng các phương thức hàng và cột để kiểm tra tính khả dụng và tái tạo khối bootstrap.
Danksharding - Tái cấu trúc
Miễn là có sẵn 50% một hàng hoặc một cột , thì Trình xác thực mẫu có thể dễ dàng xây dựng lại nó hoàn toàn. Khi họ xây dựng lại bất kỳ khối nào bị thiếu trong hàng/cột, họ sẽ phân phối lại các khối này thành các đường trực giao. Điều này giúp những người xác thực khác xây dựng lại mọi khối bị thiếu từ các hàng và cột giao nhau nếu cần.
Giả định an toàn ở đây để xây dựng lại các khối có sẵn là:
- đủ nút để Thực thi mẫu yêu cầu để chúng có đủ dữ liệu để xây dựng lại khối
- Giả định đồng bộ hóa giữa các nút phát sóng các khối tương ứng của chúng
Vậy, có bao nhiêu nút có đủ không? Ước tính sơ bộ là khoảng 64.000 trường hợp riêng lẻ (hiện tại là hơn 380.000 cho đến nay). Đây cũng là một tính toán rất bi quan khi giả định không có sự giao thoa giữa các nút được điều hành bởi cùng một trình xác thực (khác xa với tình huống các nút bị giới hạn ở 32 phiên bản ETH). Nếu bạn lấy mẫu nhiều hơn 2 hàng và cột, khả năng bạn có thể truy xuất chúng chung sẽ tăng do chéo. Điều này bắt đầu mở rộng theo tỷ lệ bậc hai - nếu trình xác thực đang chạy 10 hoặc 100 trình xác thực, thì 64.000 có thể giảm đi một số bậc độ lớn.
Nếu số lượng trình xác thực trực tuyến bắt đầu thấp bất thường, bạn có thể thiết lập DS để tự động giảm số lượng blob dữ liệu phân đoạn. Vì vậy, các giả định về an toàn sẽ được giảm xuống mức an toàn.
Danksharding – Bảo mật đa số độc hại với việc lấy mẫu ngẫu nhiên riêng tư
Chúng tôi thấy rằng việc xác minh DS dựa vào Đa số trung thực xác nhận các khối. Với tư cách cá nhân, tôi không thể chứng minh với bản thân rằng một khối có sẵn bằng cách chỉ tải xuống một vài hàng và cột. Tuy nhiên, việc lấy mẫu ngẫu nhiên riêng tư có thể mang lại cho tôi sự đảm bảo này mà không cần tin tưởng bất kỳ ai. Như đã đề cập trước đó, đây là nơi nút kiểm tra 75 mẫu ngẫu nhiên này.
DS ban đầu sẽ không bao gồm lấy mẫu ngẫu nhiên riêng tư, vì đây là một vấn đề rất khó giải quyết về mặt mạng (PSA: có thể họ thực sự cần sự trợ giúp của bạn ở đây!).
Xin lưu ý rằng "riêng tư" rất quan trọng vì nếu kẻ tấn công hủy danh tính bạn, họ có thể giả mạo một số lượng nhỏ nút lấy mẫu. Họ chỉ có thể trả lại những phần chính xác mà bạn yêu cầu và giữ phần còn lại. Do đó, bạn sẽ không biết rằng tất cả dữ liệu đều có sẵn chỉ từ việc lấy mẫu của chính bạn.
Danksharding – Bài học rút ra quan trọng
Bên cạnh cái tên ngọt ngào, DS còn rất duyên dáng và hào hứng . Cuối cùng nó đã hiện thực hóa tầm nhìn của Ethereum về một khu định cư thống nhất và lớp DA. Sự kết hợp chặt chẽ giữa các khối và mảnh Beacon này về cơ bản giả vờ không bị phân mảnh.
Trên thực tế, hãy xác định lý do tại sao nó thậm chí còn được coi là "sharding". Phần còn lại duy nhất của "sharding" là người xác thực không chịu trách nhiệm tải xuống tất cả dữ liệu. Đó là tất cả.
Vì vậy, nếu bây giờ bạn đang đặt câu hỏi liệu đây có thực sự là sharding hay không thì bạn không điên đâu. Sự khác biệt này là lý do tại sao PDS (mà chúng tôi sẽ đề cập ngay sau đây) không được coi là "sharding" (mặc dù nó có "sharding" trong tên của nó, vâng, tôi biết điều đó gây nhầm lẫn). PDS yêu cầu mỗi người xác nhận phải tải xuống đầy đủ tất cả các đốm màu phân đoạn để chứng minh tính khả dụng của chúng. DS sau đó giới thiệu mẫu để mỗi người xác nhận chỉ tải xuống một phần của mẫu.
May mắn thay, phân mảnh tối thiểu có nghĩa là thiết kế đơn giản hơn phân mảnh 1.0 (phân phối quá nhanh, phải không?). Nói một cách đơn giản, điều này bao gồm:
- So với thông số Shending 1.0, có thể có hàng trăm dòng mã trong thông số DS (ít hơn hàng nghìn dòng ở phía máy khách) row)
- Không có cơ sở hạ tầng ủy ban phân đoạn, ủy ban chỉ cần bỏ phiếu trên chuỗi chính
- Không có sự theo dõi xác nhận phân đoạn blob riêng lẻ, giờ đây tất cả đều được đưa vào chính Xác nhận chuỗi hoặc không
Kết quả tốt đẹp của việc này là một thị trường phí hợp nhất cho dữ liệu. Sharding 1.0 với các khối khác nhau được tạo bởi những người đề xuất khác nhau sẽ phân mảnh điều này.
Việc loại bỏ các ủy ban phân đoạn cũng tăng cường các nỗ lực chống hối lộ. Trình xác thực DS bỏ phiếu cho toàn bộ khối một lần trong mỗi kỷ nguyên, do đó dữ liệu được xác nhận ngay lập tức bằng 1/32 của toàn bộ bộ trình xác thực (32 vị trí trên mỗi kỷ nguyên). Trình xác thực Sharding 1.0 cũng bỏ phiếu một lần mỗi kỷ nguyên, nhưng mỗi phân đoạn có ủy ban riêng được xáo trộn. Do đó, mỗi phân đoạn chỉ được xác nhận bằng 1/2048 bộ trình xác nhận (1/32 chia thành 64 phân đoạn).
Như đã đề cập trước đó, các khối kết hợp với sơ đồ cam kết KZG 2D cũng giúp DAS hoạt động hiệu quả hơn. Sharding 1.0 yêu cầu băng thông 60 KB/s để kiểm tra DA đầy đủ của tất cả các phân đoạn. DS chỉ yêu cầu 2,5 KB/s.
Có một khả năng thú vị khác với DS - các lệnh gọi đồng bộ giữa các đợt thực thi ZK-rollup và L1 Ethereum. Các giao dịch từ các đốm màu được phân chia có thể được xác nhận và ghi vào L1 ngay lập tức vì mọi thứ đều được tạo trong cùng một khối chuỗi đèn hiệu. Sharding 1.0 sẽ loại bỏ khả năng này do các xác nhận phân đoạn riêng biệt. Điều này mang lại một không gian thiết kế thú vị có thể rất có giá trị cho những thứ như tính thanh khoản được chia sẻ (ví dụ: dAMM).
Lớp cơ sở mô-đun mở rộng quy mô một cách duyên dáng - phân cấp nhiều hơn dẫn đến mở rộng quy mô nhiều hơn. Điều này về cơ bản khác với những gì chúng ta thấy ngày nay. Việc thêm nhiều nút hơn vào tầng DA cho phép bạn tăng thông lượng dữ liệu một cách an toàn (tức là có nhiều chỗ hơn cho các bản tổng hợp tồn tại ở trên cùng).
Vẫn còn những giới hạn đối với khả năng mở rộng của blockchain, nhưng chúng ta có thể tăng nó lên theo cấp độ lớn hơn bất cứ thứ gì chúng ta thấy ngày nay. Các lớp cơ sở an toàn và có thể mở rộng cho phép việc thực thi phát triển nhanh chóng trên chúng. Theo thời gian, những cải tiến về lưu trữ dữ liệu và băng thông cũng sẽ cho phép thông lượng dữ liệu cao hơn.
Chắc chắn có thể vượt quá thông lượng DA được hình dung ở đây, nhưng rất khó để nói mức tối đa này cuối cùng sẽ ở đâu. Không có ranh giới rõ ràng, nhưng một số lĩnh vực mà các giả định bắt đầu khiến bạn cảm thấy không thoải mái:
Lưu trữ dữ liệu – Điều này liên quan đến DA so với khả năng truy xuất dữ liệu. Vai trò của lớp đồng thuận không phải là đảm bảo việc truy xuất dữ liệu vô thời hạn. Những gì nó làm là giữ nó ở trạng thái đủ lâu để bất kỳ ai quan tâm tải xuống, đáp ứng các giả định về bảo mật của chúng tôi. Sau đó, nó sẽ bị hủy ở bất cứ nơi nào nó đi - điều này thật thoải mái vì lịch sử là 1 trên N giả định về độ tin cậy và chúng ta không thực sự nói về nhiều dữ liệu đó trong sơ đồ lớn của mọi thứ. Khi sản lượng tăng lên theo nhiều cấp độ lớn, điều này có thể trở thành vấn đề đáng lo ngại trong một vài năm tới.
Trình xác thực - DAS yêu cầu có đủ nút để cùng nhau xây dựng lại khối. Nếu không, kẻ tấn công có thể đợi và chỉ trả lời các truy vấn chúng nhận được. Nếu những truy vấn được cung cấp này không đủ để xây dựng lại khối thì kẻ tấn công có thể giữ phần còn lại và chúng tôi không gặp may. Để tăng thông lượng một cách an toàn, chúng tôi cần thêm nhiều nút DAS hơn hoặc tăng yêu cầu băng thông dữ liệu của chúng. Đây không phải là vấn đề thông lượng được thảo luận ở đây. Tuy nhiên, điều này có thể trở nên khó chịu nếu thông lượng tăng thêm vài bậc so với thiết kế này.
Lưu ý rằng các nhà xây dựng không phải là nút thắt cổ chai. Bạn cần nhanh chóng tạo bằng chứng KZG cho 32 MB dữ liệu, vì vậy bạn sẽ cần GPU hoặc CPU mạnh mẽ hợp lý với băng thông ít nhất 2,5 GBit/s. Dù sao đi nữa, đó là một vai trò chuyên biệt và chi phí kinh doanh của họ không đáng kể.
Proto-danksharding (EIP-4844)
DS rất tuyệt nhưng chúng ta phải kiên nhẫn. PDS được thiết kế để giúp chúng tôi vượt qua vấn đề này - nó thực hiện các bước tương thích về phía trước cần thiết cho DS theo dòng thời gian được tăng tốc (đối với hard fork Thượng Hải) để cung cấp các đơn đặt hàng về quy mô quy mô trong thời gian tạm thời. Tuy nhiên, nó chưa thực sự triển khai việc phân chia dữ liệu (tức là người xác thực cần tải xuống tất cả dữ liệu riêng lẻ).
Bản tổng hợp ngày nay sử dụng “dữ liệu cuộc gọi” L1 để lưu trữ, dữ liệu này sẽ luôn tồn tại trên chuỗi. Tuy nhiên, Rollup chỉ yêu cầu DA trong một khoảng thời gian hợp lý để bất kỳ ai quan tâm đều có đủ thời gian tải xuống.
EIP-4844 giới thiệu một định dạng giao dịch mới hỗ trợ các đốm màu mà Rollup sẽ sử dụng để lưu trữ dữ liệu trong tương lai. Blobs mang lượng lớn dữ liệu (~125 KB) và chúng rẻ hơn nhiều so với lượng dữ liệu cuộc gọi tương tự. Các đốm màu dữ liệu sau đó sẽ bị xóa khỏi nút sau một tháng, điều này làm giảm yêu cầu lưu trữ. Đây là thời gian đủ để đáp ứng các giả định về an toàn DA của chúng tôi.
Các khối Ethereum hiện tại thường có kích thước trung bình khoảng 90 KB (dữ liệu cuộc gọi trong số đó là khoảng 10 KB). PDS mở khóa thêm băng thông DA cho các đốm màu (mục tiêu ~1 MB và tối đa ~2 MB) khi chúng được cắt bớt sau một tháng. Chúng sẽ không trở thành lực cản vĩnh viễn trên nút.
Một blob là một vectơ gồm 4096 phần tử trường, mỗi phần tử có 32 byte. PDS cho phép tối đa 16 mỗi khối, trong khi DS sẽ tăng lên 256.
Băng thông PDS DA = 4096 x 32 x 16 = 2 MiB mỗi khối, mục tiêu 1 MiB
Băng thông DS DA = 4096 x 32 x 256 = 32 MiB mỗi khối, mục tiêu 16 MiB
Mỗi bước đều có các cấp độ mở rộng. PDS vẫn yêu cầu các nút đồng thuận để tải xuống đầy đủ dữ liệu, vì vậy nó thận trọng hơn. DS phân phối tải lưu trữ và truyền dữ liệu giữa các trình xác thực.
Dưới đây là một số tính năng thú vị mà EIP-4844 được giới thiệu trên đường tới DS:
Định dạng giao dịch để mang các đốm màu dữ liệu
Cam kết của KZG đối với các đốm màu
Tất cả logic lớp thực thi được yêu cầu bởi DS
Tất cả việc thực thi /logic xác thực chéo đồng thuận theo yêu cầu của DS
Tách lớp giữa xác thực BeaconBlock và các đốm màu DAS
Hầu hết logic BeaconBlock được yêu cầu bởi DS
Tự điều chỉnh độc lập giá gas cho các đốm màu (EIP-1559 đa chiều với quy tắc định giá theo cấp số nhân)
Sau đó DS sẽ bổ sung thêm:
PBS
Hệ thống thu thập dữ liệu
Sơ đồ KZG 2D
Mọi bằng chứng ký quỹ hoặc tương tự yêu cầu trong giao thức đối với người xác thực để xác minh tính khả dụng của một phần dữ liệu phân đoạn cụ thể trong mỗi khối (có thể khoảng một tháng)
Lưu ý rằng các đốm màu dữ liệu này được giới thiệu như một loại giao dịch mới trên chuỗi thực thi, nhưng chúng không áp đặt yêu cầu bổ sung nào cho phía thực thi. EVM chỉ xem xét những lời hứa gắn liền với các đốm màu. Các thay đổi về lớp thực thi được thực hiện bằng EIP-4844 cũng tương thích về phía trước với DS và không cần thay đổi gì thêm về vấn đề này. Sau đó, việc nâng cấp từ PDS lên DS chỉ yêu cầu thay đổi lớp đồng thuận.
Blob dữ liệu được khách hàng đồng thuận tải xuống đầy đủ trong PDS. Blob hiện được tham chiếu trong phần thân khối Beacon nhưng không được mã hóa đầy đủ. Thay vì nhúng toàn bộ nội dung vào văn bản chính, nội dung của blob được truyền bá riêng biệt dưới dạng "sidecar". Mỗi khối có một sidecar blob được tải xuống đầy đủ trong PDS và sau đó DAS sẽ được thực thi trên khối đó bằng trình xác thực DS.
Trước đây chúng ta đã thảo luận về cách cam kết các đốm màu bằng cách sử dụng lời hứa đa thức KZG. Tuy nhiên, EIP-4844 không sử dụng trực tiếp KZG mà triển khai những gì chúng tôi thực sự sử dụng - các hàm băm được phiên bản của nó. Đây là byte 0x01 (đại diện cho phiên bản này), tiếp theo là 31 byte cuối cùng của hàm băm SHA256 của KZG.
Chúng tôi làm điều này để giúp đạt được khả năng tương thích EVM và khả năng tương thích về phía trước dễ dàng hơn:
Khả năng tương thích EVM – Cam kết của KZG là 48 byte, trong khi EVM sử dụng giá trị 32 byte một cách tự nhiên hơn
Khả năng tương thích chuyển tiếp – nếu chúng ta chuyển từ KZG sang thứ khác (STARK có sẵn cho kháng lượng tử), các cam kết này có thể tiếp tục với 32 byte
PDS cuối cùng sẽ tạo ra một lớp dữ liệu tùy chỉnh - các khối dữ liệu sẽ có thị trường phí riêng, với giới hạn và giá gas thả nổi riêng biệt. Vì vậy, ngay cả khi một Dự án NFT bán nhiều đất khỉ trên L1, chi phí dữ liệu tổng hợp của bạn sẽ không tăng (mặc dù chi phí thanh toán bằng chứng sẽ tăng). Điều này thừa nhận rằng chi phí chính của bất kỳ Bản tổng hợp nào hiện nay là xuất bản dữ liệu của họ lên L1 (chứ không phải bằng chứng).
Thị trường phí gas không thay đổi, các khối dữ liệu được thêm vào như một thị trường mới:
Phí blob được tính bằng gas nhưng dựa trên tự điều chỉnh số lượng có thể thay đổi đối với cơ chế EIP-1559. Số lượng đốm màu trung bình dài hạn trên mỗi khối phải bằng mục tiêu.
Trên thực tế, bạn có hai phiên đấu giá chạy song song - một để tính toán và một cho DA. Đây là một bước tiến lớn trong việc định giá tài nguyên hiệu quả.
Có một số thiết kế thú vị ở đây. Ví dụ: có thể hợp lý khi thay đổi cơ chế định giá gas và blob hiện tại từ EIP-1559 tuyến tính sang cơ chế EIP-1559 theo cấp số nhân mới. Việc triển khai hiện tại không đạt mức trung bình so với kích thước khối mục tiêu của chúng tôi trong thực tế. Ngày nay, phí cơ bản không hoàn toàn ổn định, khiến lượng gas trung bình được quan sát được sử dụng trên mỗi khối vượt quá mục tiêu trung bình khoảng 3%.
Phần II: Lịch sử & Quản lý Nhà nước
Xem nhanh một số kiến thức cơ bản tại đây :
Lịch sử - mọi thứ xảy ra trên chuỗi. Bạn có thể dán nó vào ổ cứng vì nó không cần truy cập nhanh. Về lâu dài, 1 trong số N được coi là trung thực.
Trạng thái - ảnh chụp nhanh tất cả số dư tài khoản hiện tại, hợp đồng thông minh, v.v. Các nút đầy đủ (hiện tại) yêu cầu điều này để xác thực các giao dịch. Nó quá lớn so với RAM và ổ cứng quá chậm - nó nằm trong ổ SSD của bạn. Các chuỗi khối thông lượng cao thổi phồng trạng thái của chúng vượt xa những gì mà người bình thường chúng ta có thể lưu trên máy tính xách tay của mình. Nếu người dùng hàng ngày không thể giữ trạng thái, họ không thể xác minh đầy đủ, thì hãy nói lời tạm biệt với phân cấp.
TLDR - Những thứ này có dung lượng rất lớn nên nếu bạn để nút lưu trữ chúng thì nút sẽ khó chạy. Nếu việc chạy một nút quá khó, những người bình thường như chúng ta sẽ không làm điều đó. Điều đó thật tệ, vì vậy chúng ta cần đảm bảo điều đó không xảy ra.
Giảm chi phí khí Calldata và tổng giới hạn dữ liệu cuộc gọi (EIP-4488)
PDS đã vượt qua Một bước đệm quan trọng hướng tới DS, nó kiểm tra nhiều yêu cầu cuối cùng. Việc triển khai PDS trong một khoảng thời gian hợp lý có thể nâng cao tiến độ trên DS.
Một loại Band-Aid dễ dàng hơn là EIP-4488. Nó không sang trọng bằng nhưng vẫn giải quyết được các trường hợp khẩn cấp về chi phí. Thật không may, nó không thực hiện các bước trong quá trình triển khai DS nên mọi thay đổi tất yếu vẫn sẽ cần phải thực hiện sau này. Nếu bắt đầu có cảm giác như PDS sẽ chậm hơn một chút so với mong muốn của chúng tôi, thì có thể hợp lý hơn nếu nhanh chóng chuyển EIP-4488 (chỉ là một vài dòng thay đổi mã) và sau đó triển khai PDS khoảng 6 tháng sau. Lịch trình cụ thể vẫn chưa được xác định.
EIP-4488 có hai thành phần chính:
Thay đổi chi phí calldata từ mỗi từ Phần 16 gas giảm xuống còn 3 gas mỗi byte
Thêm giới hạn 1 MB dữ liệu cuộc gọi trên mỗi khối và thêm 300 byte cho mỗi giao dịch (tối đa theo lý thuyết là khoảng 1,4 MB)
Cần thêm các giới hạn để ngăn chặn trường hợp xấu nhất - một khối chứa đầy dữ liệu cuộc gọi sẽ có dung lượng 18 MB, vượt xa những gì Ethereum có thể xử lý. EIP-4488 tăng dung lượng dữ liệu trung bình của Ethereum, nhưng do giới hạn dữ liệu cuộc gọi này (30 triệu gas / 16 gas mỗi byte dữ liệu cuộc gọi = 1,875 MB), dung lượng dữ liệu bùng nổ của nó thực sự sẽ giảm nhẹ.
Tải duy trì của EIP-4488 cao hơn nhiều so với PDS vì đây vẫn là calldata và blob, dữ liệu có thể được cắt bớt sau một tháng. EIP-4488 sẽ đẩy nhanh đáng kể tốc độ tăng trưởng lịch sử, khiến nó trở thành nút thắt cổ chai cho các nút đang chạy. Ngay cả khi EIP-4444 được triển khai cùng với EIP-4488, thao tác này sẽ chỉ xóa lịch sử tải thực thi sau một năm. Tải trọng duy trì thấp hơn trên PDS rõ ràng là mong muốn.
Liên kết dữ liệu lịch sử trong ứng dụng thực thi (EIP-4444)
EIP-4444 Cho phép khách hàng tùy chọn cắt bớt cục bộ dữ liệu lịch sử cũ hơn một năm (tiêu đề, văn bản và biên lai). Nó yêu cầu khách hàng ngừng cung cấp những dữ liệu lịch sử đã được cắt bớt này trên lớp p2 p. Lịch sử cắt bớt cho phép khách hàng giảm yêu cầu lưu trữ đĩa của người dùng (hiện tại là hàng trăm gigabyte và đang tăng lên).
Điều này vốn đã quan trọng, nhưng nếu EIP-4488 được triển khai (vì nó làm tăng đáng kể lịch sử) thì về cơ bản, điều này sẽ là bắt buộc. Dù sao, hy vọng điều này sẽ được thực hiện tương đối sớm. Cuối cùng, một số hình thức hết hạn lịch sử sẽ được yêu cầu, vì vậy đây là thời điểm tốt để giải quyết nó.
Đồng bộ hóa toàn bộ chuỗi yêu cầu lịch sử, nhưng việc xác thực các khối mới không yêu cầu lịch sử (nó chỉ yêu cầu trạng thái). Do đó, khi khách hàng đã đồng bộ hóa lên đầu chuỗi, dữ liệu lịch sử sẽ chỉ được truy xuất nếu được yêu cầu rõ ràng qua JSON-RPC hoặc nếu một máy ngang hàng cố gắng đồng bộ hóa chuỗi. Khi EIP-4444 được triển khai, chúng tôi cần tìm giải pháp thay thế cho những vấn đề này.
Khách hàng sẽ không thể thực hiện "đồng bộ hóa hoàn toàn" bằng devp2p như hiện tại - thay vào đó, họ sẽ "đồng bộ hóa điểm kiểm tra" từ các điểm kiểm tra chủ quan yếu mà họ cho rằng như khối Genesis.
Lưu ý rằng tính chủ quan yếu sẽ không phải là một giả định bổ sung - dù sao thì việc chuyển sang PoS cũng là điều cố hữu. Do khả năng bị tấn công từ xa, điều này đòi hỏi phải sử dụng các điểm kiểm tra chủ quan yếu hiệu quả để đồng bộ hóa. Giả định ở đây là máy khách sẽ không đồng bộ hóa từ một điểm kiểm tra chủ quan cũ yếu hoặc không hợp lệ. Điểm kiểm tra này phải nằm trong khoảng thời gian chúng tôi bắt đầu cắt bớt dữ liệu lịch sử (tức là trong vòng một năm ở đây), nếu không lớp p2 p sẽ không thể cung cấp dữ liệu được yêu cầu.
Khi ngày càng có nhiều khách hàng áp dụng các chiến lược đồng bộ hóa nhẹ nhàng, điều này cũng sẽ làm giảm mức sử dụng băng thông trên mạng.
Truy xuất dữ liệu lịch sử
EIP-4444 Cắt bớt dữ liệu lịch sử sau một năm nghe có vẻ Không tệ , trong khi PDS cắt bớt các đốm màu nhanh hơn (sau khoảng một tháng). Chúng tôi thực sự cần những thứ này vì chúng tôi không thể yêu cầu các nút lưu trữ tất cả chúng và duy trì tính phân cấp:
EIP-4488 – Dài hạn có thể bao gồm mọi khe cắm Khoảng 1 MB và khoảng 2,5 TB dung lượng lưu trữ được bổ sung mỗi năm
PDS – Nhắm mục tiêu khoảng 1 MB mỗi khe thời gian, thêm khoảng 2,5 TB dung lượng lưu trữ mỗi năm
DS – Nhắm mục tiêu khoảng 16 MB mỗi khe thời gian, thêm khoảng 40 TB dung lượng lưu trữ mỗi năm
Nhưng dữ liệu này sẽ đi đâu? Có phải chúng ta không còn cần thiết nữa? Có, nhưng xin lưu ý rằng việc mất dữ liệu lịch sử không phải là rủi ro đối với giao thức - chỉ đối với ứng dụng riêng lẻ. Chà, nhiệm vụ của giao thức lõi Ethereum không phải là duy trì vĩnh viễn tất cả dữ liệu đồng thuận.
Vậy ai sẽ lưu trữ nó? Dưới đây là một số người đóng góp tiềm năng:
Các tình nguyện viên cá nhân và tổ chức
Chặn máy chủ duyệt web (chẳng hạn như etherscan.io), nhà cung cấp API và các dịch vụ dữ liệu khác
Các giao thức lập chỉ mục của bên thứ ba như TheGraph có thể tạo ra các thị trường được khuyến khích nơi khách hàng có thể đóng góp cho dữ liệu lịch sử thanh toán của Máy chủ và Merkle bằng chứng
Khách hàng trong Mạng Cổng thông tin (hiện đang được phát triển) có thể lưu trữ các phần ngẫu nhiên của lịch sử chuỗi và Mạng Cổng thông tin sẽ tự động chuyển các yêu cầu dữ liệu được chuyển đến ví dụ: nút sở hữu nó
BitTorrent. Tự động tạo và phân phối tệp 7 GB chứa dữ liệu blob từ các khối mỗi ngày
Các giao thức dành riêng cho ứng dụng (chẳng hạn như Rollup) có thể yêu cầu các nút của chúng lưu trữ các phần lịch sử liên quan đến các ứng dụng của họ
Vấn đề lưu trữ dữ liệu dài hạn là một vấn đề tương đối đơn giản vì đây là giả định 1 trong N mà chúng ta đã thảo luận trước đó . Chúng ta vẫn còn nhiều năm nữa mới trở thành giới hạn cuối cùng của khả năng mở rộng blockchain.
Không có trạng thái yếu
Được rồi, vậy là chúng ta đã xử lý lịch sử Quản lý một cách khéo léo, nhưng còn tình trạng? Vấn đề trạng thái thực sự là nút thắt chính trong việc cải thiện TPS Ethereum.
Các nút đầy đủ lấy các gốc trước trạng thái, thực hiện tất cả các giao dịch trong khối và kiểm tra xem các gốc sau trạng thái có khớp với những gì chúng cung cấp trong khối hay không. Để biết liệu các giao dịch này có hợp lệ hay không, hiện tại chúng cần có sẵn trạng thái - xác minh là có trạng thái.
Bước vào kỷ nguyên không quốc tịch – chúng ta sẽ không cần nhà nước để hoạt động. Ethereum đang phấn đấu cho "tình trạng không trạng thái yếu", có nghĩa là không cần trạng thái nào để xác minh các khối, nhưng cần có trạng thái để xây dựng các khối. Việc xác thực trở thành một hàm thuần túy - hãy cung cấp cho tôi một khối hoàn toàn biệt lập và tôi có thể cho bạn biết liệu nó có hoạt động hay không. Về cơ bản nó trông như thế này:
Có thể chấp nhận được rằng các nhà xây dựng vẫn sẽ cần trạng thái do PBS - dù sao thì họ cũng sẽ là những thực thể có nguồn lực cao tập trung hơn. Tập trung vào các trình xác nhận phi tập trung. Tình trạng không quốc tịch yếu tạo ra nhiều công việc hơn cho người xây dựng và ít công việc hơn cho người xác thực. Đây là một sự đánh đổi tuyệt vời.
Bạn thực hiện được cuộc hành quyết không quốc tịch kỳ diệu này thông qua các nhân chứng. Đây là bằng chứng về quyền truy cập trạng thái chính xác mà các nhà xây dựng sẽ bắt đầu đưa vào mọi khối. Việc xác thực một khối không thực sự yêu cầu toàn bộ trạng thái - bạn chỉ cần trạng thái đã được đọc hoặc bị ảnh hưởng bởi các giao dịch trong khối. Các nhà xây dựng sẽ bắt đầu đưa các phần trạng thái bị ảnh hưởng bởi các giao dịch vào một khối nhất định và họ sẽ chứng minh rằng họ đã truy cập chính xác trạng thái đó thông qua các nhân chứng.
Hãy lấy một ví dụ. Alice muốn gửi 1 ETH cho Bob. Để xác minh khối bằng giao dịch này, tôi cần biết:
Trước khi giao dịch - Alice có 1 ETH
Khóa công khai của Alice - Vậy Tôi có thể biết chữ ký là đúng
Alice không có tên - vì vậy tôi có thể biết giao dịch đã được gửi theo đúng thứ tự
Sau khi thực hiện giao dịch - Bob có thêm 1 ETH , Alice là 1 Ít ETH hơn
Trong một thế giới không quốc tịch yếu, người xây dựng thêm dữ liệu nhân chứng ở trên vào khối và chứng minh tính chính xác của nó. Người xác nhận nhận khối, thực thi nó và quyết định xem nó có hợp lệ hay không. Đó là tất cả!
Đây là ý nghĩa của nó từ góc độ của người xác thực:
Nhu cầu về ổ SSD khổng lồ để duy trì trạng thái không còn nữa - một điểm nghẽn nghiêm trọng trong việc mở rộng quy mô ngày nay.
Yêu cầu về băng thông sẽ tăng lên vì giờ đây bạn cũng cần tải xuống dữ liệu nhân chứng và bằng chứng. Đây là nút thắt của cây Merkle-Patricia nhưng ở mức độ nhẹ chứ không phải nút thắt của nỗ lực Verkle.
Bạn vẫn thực hiện giao dịch để xác thực đầy đủ. Stateless thừa nhận rằng đây hiện không phải là nút thắt cổ chai trong việc mở rộng quy mô Ethereum.
Tình trạng không trạng thái yếu cũng cho phép Ethereum nới lỏng các giới hạn tự thân về thông lượng thực thi của nó, do đó sự phình to trạng thái không còn là vấn đề cấp bách nữa. Có thể hợp lý nếu tăng giới hạn gas lên khoảng 3 lần.
Hầu hết việc thực thi của người dùng sẽ diễn ra trên L2, nhưng thông lượng L1 cao hơn vẫn sẽ có lợi ngay cả đối với họ. Các bản tổng hợp dựa vào Ethereum để thực hiện DA (đăng lên phân đoạn) và thanh toán (yêu cầu thực thi L1). Khi Ethereum mở rộng quy mô lớp DA của nó, chi phí khấu hao của việc phát hành bằng chứng có thể sẽ chiếm một phần lớn hơn trong chi phí tổng hợp (đặc biệt là đối với các đợt tổng hợp ZK).
Verkle Tries
Chúng tôi trình bày chi tiết về cách hoạt động thực sự của những lời chứng thực này. Ethereum hiện sử dụng cây Merkle-Patricia để đại diện cho các trạng thái, nhưng bằng chứng Merkle cần thiết quá lớn để thực hiện cho những nhân chứng này.
Ethereum sẽ chuyển sang Verkle để thử nghiệm lưu trữ trạng thái. Bằng chứng Verkle hiệu quả hơn nhiều, vì vậy chúng có thể đóng vai trò là nhân chứng khả thi để đạt được tình trạng không quốc tịch yếu.
Trước tiên hãy xem cây Merkle trông như thế nào. Mọi giao dịch đều được băm - những băm này ở phía dưới được gọi là "lá". Tất cả các giá trị băm được gọi là "nút" và chúng là giá trị băm của hai nút "con" bên dưới chúng. Hàm băm cuối cùng được tạo ra là "gốc Merkle".
Đây là cấu trúc dữ liệu hữu ích để chứng minh các giao dịch có chứa mà không cần tải xuống toàn bộ cây. Ví dụ: nếu bạn muốn xác minh rằng giao dịch H4 được bao gồm, bạn chỉ cần H12, H3 và H5678 từ bằng chứng Merkle. Chúng tôi có H12345678 từ tiêu đề khối. Do đó, các máy khách hạng nhẹ có thể yêu cầu các nút đầy đủ cho các giá trị băm này và sau đó băm chúng lại với nhau dựa trên định tuyến trong cây. Nếu kết quả là H12345678 thì chúng ta đã chứng minh thành công H4 có trong cây.
Tuy nhiên, cây càng sâu thì đường đi xuống đáy càng dài nên cần nhiều dự án hơn để chứng minh điều đó. Vì vậy, cây nông và cây rộng dường như có lợi cho việc chứng minh hiệu quả.
Vấn đề là nếu bạn muốn làm cho cây Merkle rộng hơn bằng cách thêm nhiều nút con dưới mỗi nút thì sẽ rất kém hiệu quả. Bạn cần băm tất cả các anh chị em cùng nhau để leo lên cây, vì vậy bạn cần nhận được nhiều băm anh chị em hơn cho bằng chứng Merkle. Điều này sẽ làm cho kích thước bằng chứng rất lớn.
Đây là lúc những hứa hẹn về vectơ hiệu quả xuất hiện. Lưu ý rằng các hàm băm được sử dụng trong cây Merkle thực sự là các cam kết vectơ - chúng chỉ cam kết một cách hiệu quả với chỉ hai phần tử. Vì vậy, chúng tôi muốn thực hiện các lời hứa vectơ và chúng tôi không cần nhận tất cả anh chị em để xác thực nó. Khi đã có được điều đó, chúng ta có thể làm cho cây rộng hơn và giảm độ sâu của chúng. Đây là cách chúng tôi có được kích thước bằng chứng hiệu quả - giảm lượng thông tin cần cung cấp.
Bộ ba Verkle tương tự như cây Merkle, nhưng nó sử dụng các cam kết vectơ hiệu quả (do đó có tên là "Verkle") thay vì các hàm băm đơn giản cho các cây con của nó. . Vì vậy, ý tưởng cơ bản là mỗi nút có thể có nhiều nút con, nhưng tôi không cần tất cả chúng để xác minh bằng chứng. Đó là bằng chứng về kích thước không đổi bất kể chiều rộng.
Trên thực tế, trước đây chúng tôi đã đưa ra một ví dụ điển hình về một trong những khả năng này - các cam kết KZG cũng có thể được sử dụng làm cam kết vectơ. Trên thực tế, đây chính là thứ mà các nhà phát triển Ethereum ban đầu dự định sử dụng ở đây. Kể từ đó, họ đã chuyển sang Pedersen hứa hẹn những nhiệm vụ tương tự. Chúng sẽ dựa trên các đường cong elip (trong trường hợp này là Bandersnatch) và chúng sẽ gửi 256 giá trị cho mỗi đường cong (tốt hơn nhiều so với hai!).
Vậy tại sao không có cây có chiều sâu càng rộng càng tốt? Điều này rất hữu ích cho những người xác nhận hiện có bằng chứng siêu nhỏ gọn. Nhưng có một sự đánh đổi thực tế là người chứng minh cần có khả năng tính toán bằng chứng, và nó càng rộng thì càng khó. Do đó, những nỗ lực của Verkle này sẽ nằm giữa các cực có chiều rộng 256 giá trị.
Hết hạn trạng thái
Tình trạng không trạng thái yếu sẽ loại bỏ hạn chế mở rộng trạng thái của trình xác thực, nhưng Trạng thái thì không biến mất một cách kỳ diệu. Chi phí giao dịch bị hạn chế nhưng chúng tạo ra thuế vĩnh viễn trên mạng bằng cách tăng trạng thái. Sự tăng trưởng của nhà nước vẫn là lực cản vĩnh viễn trên mạng. Cần phải làm gì đó để giải quyết vấn đề cơ bản.
Đây là nơi trạng thái hết hạn. Việc không hoạt động trong một khoảng thời gian dài (chẳng hạn như một hoặc hai năm) thậm chí sẽ loại bỏ nó khỏi những gì người xây dựng khối cần phải thực hiện. Người dùng đang hoạt động sẽ không nhận thấy bất kỳ điều gì và trạng thái không sử dụng không còn cần thiết có thể bị loại bỏ.
Nếu cần khôi phục trạng thái đã hết hạn, bạn chỉ cần xuất trình chứng chỉ và kích hoạt lại nó. Điều này quay trở lại giả định lưu trữ 1 trong N ở đây. Miễn là ai đó vẫn có toàn bộ lịch sử (block explorer, v.v.), bạn có thể nhận được những gì bạn cần từ họ.
Tình trạng không trạng thái yếu làm suy yếu nhu cầu hết hạn trạng thái ngay lập tức của lớp cơ sở, nhưng về lâu dài, đặc biệt là khi thông lượng L1 tăng lên, đây là một điều tốt. Đây sẽ là một công cụ hữu ích hơn để tổng hợp thông lượng cao. Trạng thái L2 sẽ tăng ở mức độ cao hơn, kéo theo cả những nhà xây dựng hiệu suất cao.
Phần III - MEV
PBS là cần thiết để triển khai DS một cách an toàn, nhưng hãy nhớ lại rằng thực ra ban đầu nó được thiết kế để chống lại sức mạnh tập trung của MEV. Bạn sẽ nhận thấy xu hướng định kỳ trong nghiên cứu Ethereum ngày nay – MEV hiện là trung tâm của kinh tế học tiền điện tử.
Thiết kế một blockchain với MEV là rất quan trọng để duy trì tính bảo mật và phân quyền. Cách tiếp cận cấp giao thức cơ bản là:
Giảm thiểu MEV có hại càng nhiều càng tốt (ví dụ: xác định một vị trí, bầu cử lãnh đạo bí mật duy nhất)
Dân chủ hóa phần còn lại (ví dụ: MEV-Boost, PBS, MEV Smoothing)
Phần còn lại phải dễ dàng được nắm bắt và chia sẻ giữa các trình xác thực trải rộng. Nếu không, nó sẽ tập trung bộ trình xác thực do không thể cạnh tranh với những người tìm kiếm phức tạp. Điều này càng trở nên trầm trọng hơn bởi thực tế là MEV sau sáp nhập sẽ có tỷ lệ phần thưởng xác thực cao hơn (việc phát hành đặt cược thấp hơn nhiều so với tỷ lệ lạm phát dành cho người khai thác). Không thể bỏ qua.
Chuỗi cung ứng MEV ngày nay
Chuỗi sự kiện hôm nay như sau:
Các nhóm khai thác đóng vai trò là người xây dựng ở đây. Người tìm kiếm MEV chuyển tiếp các gói giao dịch (và giá thầu tương ứng của chúng) tới nhóm khai thác thông qua Flashbot. Nhà điều hành nhóm tổng hợp một khối hoàn chỉnh và chuyển các tiêu đề khối cho từng người khai thác. Những người khai thác chứng minh điều này bằng cách đưa ra trọng số trong các quy tắc lựa chọn nhánh thông qua PoW.
Flashbots xuất hiện để ngăn chặn sự tích hợp theo chiều dọc của toàn bộ hệ thống - điều này sẽ mở ra cánh cửa cho sự kiểm duyệt và các tác động bên ngoài khó chịu khác. Vào thời điểm Flashbots xuất hiện, các nhóm khai thác đã bắt đầu đạt được các thỏa thuận độc quyền với các công ty thương mại để rút MEV. Thay vào đó, Flashbots cung cấp cho họ một cách dễ dàng để tổng hợp giá thầu MEV và tránh tích hợp dọc (bằng cách triển khai MEV-geth).
Sau khi sáp nhập Ethereum, nhóm khai thác sẽ biến mất. Chúng tôi muốn mở ra cánh cửa cho các nút xác thực có thể được chạy ở nhà một cách hợp lý. Điều này đòi hỏi phải tìm ai đó đảm nhận vai trò xây dựng chuyên dụng. Nút xác thực tại nhà của bạn có thể không thu được MEV tốt như một quỹ phòng hộ với mức lương được định lượng. Nếu không được chọn, điều này sẽ tập trung bộ trình xác thực nếu người bình thường không thể cạnh tranh. Nếu được cấu trúc đúng cách, giao thức có thể chuyển hướng doanh thu MEV sang thu nhập đặt cược hàng ngày của người xác thực.
MEV-Boost
Thật không may, PBS trong giao thức không thể sẵn sàng vào thời điểm hợp nhất. Flashbots một lần nữa đưa ra giải pháp bước đệm - MEV-Boost.
Theo mặc định, trình xác thực được hợp nhất sẽ nhận các giao dịch mempool công khai trực tiếp vào ứng dụng thực thi của nó. Họ có thể đóng gói những thứ này lại, đưa chúng cho các khách hàng đồng thuận và sau đó phát chúng lên mạng. (Nếu bạn cần hiểu cách các ứng dụng khách đồng thuận và thực thi của Ethereum phối hợp với nhau, tôi sẽ trình bày vấn đề đó trong phần bốn).
Nhưng như chúng ta đã thảo luận, trình xác thực của bạn không biết cách trích xuất MEV, vì vậy Flashbots cung cấp một tùy chọn khác. MEV-boost sẽ kết nối với ứng dụng khách đồng thuận của bạn, cho phép bạn thuê ngoài việc xây dựng khối chuyên dụng. Điều quan trọng là bạn vẫn có tùy chọn sử dụng ứng dụng khách thực thi của riêng mình làm dự phòng.
Những người tìm kiếm MEV sẽ tiếp tục đóng vai trò như ngày nay. Họ sẽ thực hiện các chiến lược cụ thể (chênh lệch giá thống kê, chênh lệch giá nguyên tử, bánh kẹp, v.v.) và đặt giá thầu trên các gói của họ. Sau đó, người xây dựng tổng hợp tất cả các gói mà họ nhìn thấy, cũng như mọi luồng đơn đặt hàng riêng tư (ví dụ: từ Flashbots Protect) thành khối đầy đủ tốt nhất. Các nhà xây dựng chỉ chuyển các tiêu đề khối cho người xác thực thông qua rơle chạy tới MEV-Boost. Flashbots có ý định chạy các trình chuyển tiếp và trình xây dựng cũng như có kế hoạch phân quyền theo thời gian, nhưng việc đưa các trình xây dựng khác vào danh sách trắng có thể bị chậm.
MEV-Boost yêu cầu người xác nhận phải tin cậy người chuyển tiếp - ứng dụng khách đồng thuận nhận tiêu đề khối, ký tên và sau đó hiển thị nội dung khối. Mục đích của người chuyển tiếp là để chứng minh cho người đề xuất rằng nội dung đó là hợp lệ và tồn tại để người xác nhận không cần phải tin tưởng trực tiếp vào người xây dựng.
Khi PBS trong giao thức đã sẵn sàng, nó sẽ được lập trình với nội dung do MEV-Boost cung cấp trong thời gian chờ đợi. PBS cung cấp sự phân chia quyền lực tương tự, cho phép phân cấp người xây dựng dễ dàng hơn và loại bỏ nhu cầu người đề xuất phải tin tưởng bất kỳ ai.
Việc điều chỉnh MEV do ủy ban chỉ đạo
PBS cũng mở ra cơ hội cho một ý tưởng hay ho khác - việc điều chỉnh MEV do ủy ban điều hành.
Chúng tôi thấy rằng khả năng trích xuất MEV là sức mạnh tập trung của bộ trình xác thực, nhưng việc phân phối cũng vậy. Tính biến thiên cao của phần thưởng MEV từ khối này sang khối khác thúc đẩy việc tập hợp nhiều trình xác nhận để làm mịn phần thưởng của bạn (như chúng ta thấy với các nhóm khai thác ngày nay, mặc dù ở mức độ thấp hơn ở đây).
Cài đặt mặc định là cung cấp khoản thanh toán đầy đủ của người xây dựng cho người đề xuất khối thực tế. Thay vào đó, việc làm mịn MEV sẽ phân phối thanh toán giữa nhiều người xác nhận. Một ủy ban gồm những người xác nhận sẽ kiểm tra khối được đề xuất và xác nhận xem đây có thực sự là khối có giá thầu cao nhất hay không. Nếu mọi việc suôn sẻ, khối sẽ tiếp tục và phần thưởng được chia giữa ủy ban và người đề xuất.
Điều này cũng giải quyết được một vấn đề khác - hối lộ ngoài quy định. Ví dụ: những người đề xuất có thể được khuyến khích gửi các khối dưới mức tối ưu và trực tiếp nhận hối lộ ngoài phạm vi để che giấu khoản thanh toán của họ với người được ủy quyền. Bằng chứng này kiểm tra người đề xuất.
PBS nội giao thức là điều kiện tiên quyết để làm trơn MEV. Bạn cần hiểu thị trường xây dựng và gửi giá thầu rõ ràng. Có một số câu hỏi nghiên cứu mở ở đây, nhưng đây là một đề xuất thú vị sẽ rất quan trọng để đảm bảo một lần nữa các trình xác thực phi tập trung.
Tính cuối cùng của giao dịch một vị trí
Tính cuối cùng nhanh chóng là điều tuyệt vời. Chờ ~15 phút là không tối ưu cho trải nghiệm người dùng hoặc giao tiếp xuyên chuỗi. Quan trọng hơn, điều này tạo ra vấn đề về tổ chức lại MEV.
Ethereum được sáp nhập đã cung cấp xác nhận mạnh mẽ hơn hiện nay - hàng nghìn người xác thực chứng thực mỗi khối cạnh tranh với các thợ mỏ và có khả năng Khai thác ở cùng độ cao khối mà không cần bỏ phiếu. Điều này sẽ khiến việc tái tổ chức trở nên cực kỳ khó xảy ra. Tuy nhiên, đây vẫn chưa phải là bản cuối cùng thực sự của thỏa thuận. Nếu khối cuối cùng có một số MEV lớn, bạn có thể lừa những người xác thực cố gắng sắp xếp lại chuỗi và đánh cắp nó cho chính họ.
Tính xác định của một khe duy nhất loại bỏ mối đe dọa này. Việc khôi phục khối cuối cùng yêu cầu ít nhất một phần ba số người xác thực và mã thông báo đặt cược của họ sẽ bị cắt giảm ngay lập tức (hàng triệu ETH).
Tôi sẽ không quá chú trọng vào cơ chế cơ bản ở đây. Tính hữu hạn của một khe cắm đã đi rất xa trong lộ trình của Ethereum và đó là một không gian thiết kế rất mở.
Trong giao thức đồng thuận ngày nay (không có tính hữu hạn của vị trí), Ethereum chỉ yêu cầu 1/32 người xác thực để chứng nhận từng vị trí (hiện tại có khoảng 380.000 (khoảng 12.000 người trong số họ). Việc mở rộng quy mô loại bỏ phiếu này thành tập hợp đầy đủ các trình xác thực bằng cách sử dụng tính năng tổng hợp chữ ký BLS trong một vị trí duy nhất đòi hỏi nhiều công việc hơn. Điều này nén hàng trăm nghìn phiếu bầu vào một xác minh duy nhất:
Vitalik phân tích một số giải pháp thú vị tại đây.
Cuộc bầu cử lãnh đạo bí mật duy nhất (SSLE)
SSLE cố gắng khắc phục những gì chúng ta sẽ phải đối mặt sau đó sự sáp nhập Một vectơ tấn công MEV khác.
Danh sách trình xác thực Beacon Chain và danh sách lựa chọn người lãnh đạo sắp tới là công khai và có thể dễ dàng hủy ẩn danh cũng như ánh xạ địa chỉ IP của họ. Bạn có thể thấy vấn đề ở đây.
Các trình xác thực phức tạp hơn có thể sử dụng các thủ thuật để ẩn mình tốt hơn, nhưng các trình xác thực nhỏ hơn đặc biệt dễ bị ảnh hưởng bởi doxxed và DDOSd sau đó. Điều này có thể dễ dàng sử dụng cho MEV.
Giả sử bạn là người đề xuất khối n và tôi là người đề xuất khối n+1. Nếu tôi biết địa chỉ IP của bạn, tôi có thể DDOS với giá rẻ để bạn hết thời gian chờ và không tạo được khối. Bây giờ tôi có thể nắm bắt MEV của slot của chúng tôi và nhân đôi phần thưởng của mình. Điều này càng trở nên trầm trọng hơn do kích thước khối đàn hồi của EIP-1559 (gas tối đa trên mỗi khối gấp đôi kích thước mục tiêu), vì vậy tôi có thể nhồi nhét các giao dịch lẽ ra là hai khối vào khối mà tôi hiện có dài gấp đôi trong một khối.
Các nút xác thực gia đình có thể từ bỏ việc xác thực vì chúng liên tục bị tấn công. SSLE làm cho không ai ngoài người đề xuất biết khi nào đến lượt họ ngăn chặn một cuộc tấn công như vậy. Điều này sẽ không có hiệu lực vào thời điểm hợp nhất nhưng hy vọng nó sẽ sớm được triển khai.
Phần IV - Sáp nhập
Được rồi, nói rõ là trước đây tôi chỉ nói đùa thôi. Tôi thực sự nghĩ (hy vọng) rằng việc sáp nhập Ethereum diễn ra tương đối nhanh chóng.
Tất cả chúng ta đang nói về chủ đề này, vì vậy tôi cảm thấy ít nhất phải giới thiệu ngắn gọn về nó.
Khách hàng đã hợp nhất
Ngày nay, bạn điều hành một khách hàng duy nhất xử lý mọi thứ khách hàng (ví dụ: Sử dụng Ethereum, Nethermind, v.v.). Cụ thể, các nút đầy đủ thực hiện đồng thời các hoạt động sau:
Thực thi - Thực hiện mọi giao dịch trong một khối để đảm bảo tính hợp lệ. Lấy gốc trạng thái trước, thực hiện tất cả các thao tác và kiểm tra xem gốc trạng thái sau được tạo có chính xác hay không
Đồng thuận - xác minh rằng bạn đang ở trên chuỗi nặng nhất (PoW cao nhất) đã thực hiện nhiều công việc nhất ( tức là Sự đồng thuận của Satoshi)
Chúng không thể tách rời vì các nút đầy đủ không chỉ đi theo chuỗi nặng nhất mà còn đi theo chuỗi hợp lệ nặng nhất. Đó là lý do tại sao chúng là nút đầy đủ chứ không phải nút nhẹ. Ngay cả khi xảy ra cuộc tấn công 51%, các nút đầy đủ sẽ không chấp nhận các giao dịch không hợp lệ.
Beacon Chain hiện chỉ chạy đồng thuận để chạy thử nghiệm PoS. Không bao gồm việc thực hiện. Tổng độ khó cuối cùng cuối cùng sẽ được xác định, tại thời điểm đó, các khối thực thi Ethereum hiện tại sẽ được hợp nhất thành các khối chuỗi đèn hiệu, tạo thành một chuỗi:
Tuy nhiên, nút đầy đủ sẽ chạy hai ứng dụng khách độc lập ở chế độ nền. có thể tương tác:
Máy khách thực thi (còn gọi là "máy khách Eth1") - máy khách Eth 1.0 hiện tại tiếp tục xử lý việc thực thi. Chúng xử lý các khối, duy trì nhóm bộ nhớ cũng như quản lý và đồng bộ hóa trạng thái. Phần PoW đã bị loại bỏ.
Ứng dụng đồng thuận (hay còn gọi là "Khách hàng Eth2") - Ứng dụng khách Beacon Chain hiện tại tiếp tục xử lý sự đồng thuận PoS. Họ theo dõi người đứng đầu chuỗi, buôn chuyện và chứng nhận các khối, đồng thời nhận phần thưởng cho người xác nhận.
Khách hàng nhận được khối chuỗi beacon, thực hiện giao dịch do khách hàng thực hiện và nếu mọi việc suôn sẻ, khách hàng đồng thuận sẽ tuân theo chuỗi. Bạn sẽ có thể kết hợp các ứng dụng khách thực thi và đồng thuận mà bạn chọn, tất cả đều có thể tương tác với nhau. API công cụ mới sẽ được giới thiệu để khách hàng giao tiếp với nhau:
Hoặc:
Sự đồng thuận sau sáp nhập
Nakamoto ngày nay Sự đồng thuận của Satoshi rất đơn giản. Người khai thác tạo các khối mới và thêm chúng vào chuỗi hợp lệ nặng nhất được quan sát.
Ethereum sau sáp nhập chuyển sang GASPER - kết hợp Casper FFG (công cụ cuối cùng) và LMD GHOST (quy tắc lựa chọn ngã ba) để đạt được sự đồng thuận. TLDR ở đây - đây là sự sống động ủng hộ sự đồng thuận, không phải bảo mật.
Sự khác biệt là các thuật toán đồng thuận thiên về bảo mật (ví dụ: Tendermint) không đạt được số phiếu bầu cần thiết (ở đây được đặt là 2/3 số người xác thực) . ). Việc ủng hộ tính sống động của chuỗi (ví dụ: Đồng thuận PoW + Satoshi) dù sao cũng sẽ tiếp tục xây dựng một sổ cái lạc quan, nhưng nếu không có đủ phiếu bầu thì họ không thể đạt được kết quả cuối cùng. Bitcoin và Ethereum ngày nay không bao giờ được hoàn thiện - bạn chỉ cần cho rằng việc tổ chức lại sẽ không xảy ra sau khi có đủ số khối.
Tuy nhiên, Ethereum cũng sẽ đạt được mục tiêu cuối cùng thông qua các điểm kiểm tra thường xuyên nếu nhận được đủ số phiếu bầu. Mỗi phiên bản 32 ETH là một trình xác thực riêng lẻ và đã có hơn 380.000 trình xác thực Chuỗi Beacon. Các kỷ nguyên bao gồm 32 vị trí, với tất cả các trình xác thực được phân chia và chứng thực cho một vị trí trong một kỷ nguyên nhất định (nghĩa là ~12.000 lần chứng thực trên mỗi vị trí). Quy tắc lựa chọn ngã ba LMD Ghost sau đó xác định người đứng đầu chuỗi hiện tại dựa trên những bằng chứng này. Một khối mới được thêm vào mỗi vị trí (12 giây), vì vậy thời gian là 6,4 phút. Tính cuối cùng thường đạt được với số phiếu bầu cần thiết sau hai kỷ nguyên (nghĩa là 64 vị trí, mặc dù có thể cần tới 95 vị trí).
Kết luận
Mọi con đường đều dẫn đến sản xuất và phân cấp khối tập trung. chống lại sự xác minh và kiểm duyệt. Lộ trình của Ethereum hướng tới tầm nhìn này.
Ethereum đặt mục tiêu trở thành DA và lớp thanh toán thống nhất cuối cùng - phi tập trung và bảo mật ồ ạt ở phía dưới, có khả năng mở rộng tính toán ở phía trên. Điều này cô đọng các giả định về mật mã thành một lớp mạnh mẽ. Lớp cơ sở mô-đun thống nhất bao gồm việc thực thi cũng thu được giá trị cao nhất trong thiết kế L1 – đạt được phí bảo hiểm tiền tệ và an ninh kinh tế, như tôi đã giới thiệu gần đây (và hiện là nguồn mở tại đây).
Tôi hy vọng bạn hiểu rõ hơn về cách kết hợp nghiên cứu Ethereum. Chúng tôi có rất nhiều bài viết cảm động, rất tiên tiến và có một bức tranh rất lớn bao quanh tâm trí bạn.
Về cơ bản, tất cả đều xoay quanh tầm nhìn duy nhất đó. Ethereum đưa ra một con đường hấp dẫn để đạt được khả năng mở rộng quy mô lớn đồng thời trân trọng những giá trị mà chúng tôi quan tâm sâu sắc trong không gian này.
Đặc biệt cảm ơn Dankrad Feist vì những nhận xét và hiểu biết sâu sắc của ông.
Liên kết gốc
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
