Giả sử bạn có một số lượng lớn các đối tượng có thể được người dùng gửi đi, và tất cả (nếu hợp lệ) cần được phát sóng để chúng có thể được phát hiện và đưa vào bởi một nút xây dựng cuối cùng nào đó. Giả sử điều kiện hợp lệ cũng có thể được biểu diễn trong một STARK, và chúng ta đang ở trong một môi trường hậu lượng tử, nơi mà các SNARK đường cong elip sẽ không hoạt động.
Điều này áp dụng trong ít nhất ba trường hợp sử dụng trong Ethereum:
- Tổng hợp chữ ký ở lớp thực thi hậu lượng tử, đặc biệt nếu người dùng đang sử dụng các giao thức bảo mật.
- Tổng hợp chữ ký lớp đồng thuận hậu lượng tử, để xử lý số lượng lớn người xác thực.
- Phát sóng các gốc blob, trong mô hình xây dựng khối phân tán, nơi chúng ta giả định rằng tổng số lượng blob quá lớn để người xây dựng có thể tải xuống hoàn toàn, và do đó người xây dựng phải tải xuống các gốc từ người gửi blob và sau đó sử dụng DAS để xác minh tính khả dụng của chúng. STARK xác minh rằng mã hóa xóa đã được tính toán chính xác.
Vấn đề: STARK rất tốn kém, chiếm tới 128 kB ngay cả trong các triển khai được tối ưu hóa kích thước cao. Nếu mỗi đối tượng do người dùng gửi được phát sóng đến tất cả mọi người cùng với toàn bộ 128 kB chi phí phụ trội của STARK, thì nhu cầu băng thông (cả đối với các nút mempool trung gian và đối với trình tạo) sẽ trở nên quá lớn.
Đây là cách chúng ta có thể giải quyết vấn đề này.
Khi người dùng gửi một đối tượng vào mempool, họ có thể gửi đối tượng đó cùng với bằng chứng xác thực trực tiếp (ví dụ: một hoặc nhiều chữ ký, dữ liệu gọi EVM vượt qua một số hàm xác thực), hoặc một STARK chứng minh tính hợp lệ.
Các nút Mempool tuân theo thuật toán sau:
- Chúng chờ đợi một cách thụ động và nhận các đối tượng từ người dùng. Khi thấy một đối tượng, chúng sẽ xác thực bằng chứng của nó. Nếu bằng chứng hợp lệ, chúng sẽ chấp nhận nó.
- Cứ mỗi chu kỳ (ví dụ: 500ms), chúng tạo ra một chứng chỉ STARK đệ quy chứng minh tính hợp lệ của tất cả các đối tượng vẫn còn hợp lệ mà chúng biết. Chúng chuyển tiếp bằng chứng này cho các máy ngang hàng, đồng thời gửi cho mỗi máy ngang hàng bất kỳ đối tượng nào (không kèm bằng chứng) mà chúng chưa gửi cho máy ngang hàng đó.
Logic của thuật toán STARK đệ quy như sau: Đầu vào công khai là một trường bit hoặc một danh sách các hàm băm, đại diện cho tập hợp các đối tượng mà bằng chứng chứng minh tính hợp lệ. Sau đó, bằng chứng mong đợi:
- 0 hoặc nhiều đối tượng, kèm theo bằng chứng xác thực của chúng (bằng chứng trực tiếp hoặc bằng chứng STARK)
- 0 hoặc nhiều STARK đệ quy khác cùng loại
- Một trường bit chứa danh sách băm các đối tượng cần loại bỏ (điều này cho phép loại bỏ các đối tượng đã hết hạn).
Bằng chứng này chứng minh tính hợp lệ của sự kết hợp giữa tất cả các đối tượng và tất cả các đầu vào công khai của các stark đệ quy được đưa vào đó, trừ đi các đối tượng bị loại bỏ.
Dưới dạng sơ đồ (ở đây, dành cho trường hợp sử dụng tổng hợp chữ ký ở lớp thực thi):
Trong ví dụ này, nút mempool đầu tiên thấy Tx 1 và Tx 2 (với bằng chứng trực tiếp), và tạo ra một STARK đệ quy chứng minh rằng {Tx 1, Tx 2} là hợp lệ. Nút mempool thứ hai thấy thông báo từ nút đầu tiên, chứa Tx 1 và Tx 2 (không có bằng chứng trực tiếp) cộng với STARK, và nó cũng thấy Tx 3 (với bằng chứng trực tiếp), và nó tạo ra một STARK đệ quy chứng minh rằng {Tx 1, Tx 2, Tx 3} là hợp lệ. Nó gửi thông báo này đến các nút ngang hàng, trong đó có một nút là builder, nút này nhận và đưa thông báo vào.
Nếu trình xây dựng nhận được nhiều thông báo chứa các tập hợp đối tượng không hoàn toàn trùng lặp và trình xây dựng muốn bao gồm cả hai, trình xây dựng có thể tự tạo một STARK đệ quy để kết hợp chúng. Trình xây dựng cũng có thể loại bỏ bất kỳ đối tượng nào (ở đây là các giao dịch) mà họ thấy không còn hợp lệ để đưa vào.
Tổng chi phí phát sinh của phương án này là:
- Mỗi đối tượng, nếu không có bằng chứng xác thực, sẽ được phát sóng đến từng nút mạng. Điều này có cùng băng thông như hiện trạng hiện nay, ngoại trừ việc chúng ta có thể loại bỏ chữ ký.
- Mỗi nút có thêm băng thông vào và ra bằng kích thước của một STARK mỗi tick, nhân với số lượng nút ngang hàng của nó (ví dụ: với 8 nút ngang hàng và tick 500ms, đó là 128 kB * 8 / 0,5 = 2 MB/giây). Giá trị này là không đổi và không tăng lên khi số lượng đối tượng mà người dùng gửi vào tăng lên.
