Các biến thể của Vé Mempool

Bài viết này tóm tắt các cuộc thảo luận tại cuộc họp gần đây của Nhóm khuyến khích mạnh mẽ với sự đóng góp ý kiến từ tất cả các thành viên RIG và Francesco.

Việc phân mảnh theo chiều dọc mempool sẽ giải phóng băng thông cho trình xác thực sử dụng mempool lớp thực thi, vì trình xác thực chỉ cần tải xuống các mẫu blob trong mempool thay vì toàn bộ blob. Việc giảm băng thông sử dụng cho mempool blob đặc biệt quan trọng vì số lượng blob sẽ tăng khoảng 8 lần với PeerDAS , bản nâng cấp lớn tiếp theo dự kiến sẽ ra mắt trên Ethereum vào cuối năm 2025.

Chỉ việc tải xuống các mẫu dữ liệu mới mở ra một cuộc tấn công DoS cần được giải quyết. Dankrad đề xuất sử dụng một số hình thức thanh toán trước để đảm bảo thanh toán và hạn chế số lượng sybil có thể làm tràn bộ nhớ. Francesco sau đó đã đề xuất một hình thức bảo vệ sybil cụ thể gọi là vé mempool.

Hai vấn đề chính với đề xuất vé mempool hiện tại là:

• Gas : Cơ chế phân bổ vé mempool yêu cầu người dùng gửi các giao dịch, khác với giao dịch blob, để mua vé mempool. Các giao dịch này tiêu tốn gas. Cơ chế này không nên tiêu tốn quá nhiều gas vì lượng gas đó sẽ được dành cho người dùng thông thường.

• Trải nghiệm người dùng: Cơ chế phân bổ vé mempool yêu cầu người dùng phải mua vé trước. Điều này làm thay đổi trải nghiệm người dùng vì người dùng cần lên kế hoạch trước về lượng nhu cầu dự kiến. Mức độ thay đổi đối với trải nghiệm người dùng có thể rất nhỏ trong một số thiết kế (ví dụ: đề xuất Vé Mempool Đơn giản bên dưới), nhưng lại rõ rệt hơn trong các thiết kế khác (ví dụ: Thuê Mempool LIFO). Trong trường hợp đặc biệt khi một rollup phải đăng một blob ngay lập tức và không mong đợi điều đó, rollup luôn có thể đăng thông qua calldata.

Đặc biệt khó để dự đoán trải nghiệm người dùng tốt sẽ như thế nào, vì lưu lượng blob hiện tại gần như nhỏ hơn gấp bội so với những gì chúng ta kỳ vọng sẽ đạt được trong ngắn hạn nhờ PeerDAS và các cải tiến về mạng. Cả việc tăng lưu lượng và các phiếu mempool đều sẽ thay đổi trải nghiệm người dùng, và rất khó để dự đoán tác động của tương tác giữa chúng.

Tuy nhiên, việc cải tiến Mempool là rất cần thiết. Do đó, trong bài viết này, chúng tôi:

• Đưa ra 3 đề xuất về cách triển khai vé mempool và khám phá những đánh đổi của chúng.

• Xin lưu ý rằng không cần hard fork để triển khai vé mempool vì mempool phân mảnh theo chiều dọc là một bản nâng cấp mạng không yêu cầu hard fork và bản thân vé mempool có thể được triển khai thông qua hợp đồng thông minh. Hợp đồng thông minh có thể được thay đổi tương đối dễ dàng trong tương lai để phù hợp với những thay đổi trong hành vi của trình gửi blob.

Vé bán buôn

Cơ chế bán buôn vé cho phép người gửi blob mua một lượng vé tương đối lớn cùng một lúc. Trong mỗi slot, số vé bán ra gấp k lần số blob được cung cấp, ví dụ, chúng ta có thể bán được 90 vé blob ngay cả khi chỉ có thể đưa tối đa 9* blob vào một slot ( k = 10). Việc cung cấp quá nhiều vé cho phép người gửi blob mua vé cho nhiều slot cùng một lúc, điều này có thể dễ dàng hơn về mặt vận hành. Việc bán vé trong mỗi slot đảm bảo rằng những người cần vé cho slot tiếp theo vẫn có thể mua được vé và ngăn chặn tình trạng kiểm duyệt thường xảy ra nếu bạn chỉ bán vé trong một slot.

Cơ chế hoạt động như sau:

• Mua: Các đơn hàng theo mẫu (sender_ID, number_of_tickets) được gửi đến hợp đồng thông minh trong mỗi khung giờ.

• Phân bổ: Hợp đồng thông minh lấy đầu vào là các đơn hàng và xuất ra danh sách sender_ID , allocated_tickets tương ứng và ticket_expiry_slot , tương tự như thời điểm vé hết hạn. Đối với mỗi đơn hàng tương tác với hợp đồng thông minh, nó sẽ phân bổ \\max(\\text{số lượng\\\_of\\\_tickets}, \\text{tickets\\_left}) m a x ( số tiếp theo​​​​​​​ _ của​ _ vé ,​​​​​​ văn bản vé​​​​​​​​ _ l e f t ) , trong đó tickets_left là biến bằng với hiệu số giữa tổng số vé và số vé đã được phân bổ. Việc phân bổ diễn ra trong mỗi vị trí có ít nhất một đơn hàng.

• Lan truyền blob: Người giữ vé có thể lan truyền một blob cho mỗi vé họ giữ trong bất kỳ khe nào. Mỗi nút tham gia vào mempool phân mảnh theo chiều dọc sẽ duy trì một danh sách cục bộ về số lượng vé mà mỗi sender_ID còn lại. Sau khi xem các mẫu của một blob duy nhất, nút sẽ cập nhật danh sách cục bộ của mình bằng cách trừ 1 khỏi number_of_tickets .

Vé hết hạn vì nếu không, có thể có một lượng vé dự trữ lớn, cho phép quá nhiều blob được lan truyền trong mempool cùng một lúc, từ đó có thể tạo ra một vectơ DoS. Các tham số được thiết lập ở đây cần được kiểm tra, tuy nhiên, có một sự đánh đổi rõ ràng giữa hệ số cung vượt cầu k và thời hạn hiệu lực ảnh hưởng đến ticket_expiry_slot . Nếu vé có thời hạn dài hơn, chúng ta nên bán ít vé hơn cho mỗi slot để có cùng số lượng vé hợp lệ tối đa còn lại.

Chúng tôi không đề xuất hoàn lại tiền vé ở đây như đã đề xuất trước đây, vì việc hoàn lại tiền vé đòi hỏi một hệ thống tốn kém hơn về mặt xăng.

Cho thuê Mempool

Cơ chế cho thuê mempool này cho phép một số người giữ vé giữ vé của họ trong thời gian dài hơn, đồng thời cho phép bất kỳ ai cũng có thể mua vé trong mỗi slot. Cơ chế này thực hiện điều này bằng cách lưu giữ danh sách những người được gọi là người thuê. Người thuê mới có thể tham gia nhóm bằng cách đặt cọc cao hơn mức đặt cọc thấp nhất hiện có trong nhóm, hoặc bằng cách đặt cọc tối thiểu và loại bỏ người thuê đã ở trong nhóm trong thời gian ngắn nhất.

Cơ chế hoạt động như sau:

• Mua: Các lệnh theo mẫu (sender_ID, number_of_leases, deposit_per_lease) được gửi đến hợp đồng thông minh ở bất kỳ vị trí nào.

• Phân bổ: Chúng tôi đưa ra hai lựa chọn phân bổ. Lựa chọn đầu tiên là hệ thống dựa trên cổ phần, tương tự như bộ xác thực có giới hạn được sử dụng trong một số blockchain. Lựa chọn thứ hai là hệ thống vào sau ra trước, nhằm mục đích giữ lại những người nắm giữ hợp đồng thuê có khả năng gửi lại blob sớm nhất trong bộ để giảm thiểu việc luân chuyển.

  • Tùy chọn đặt cọc: Hợp đồng thông minh duy trì một danh sách có độ dài N , chứa các chủ sở hữu hợp đồng thuê dưới dạng (sender_ID, deposit) cho mỗi chủ sở hữu hợp đồng thuê. Đối với mỗi lệnh tương tác với hợp đồng thông minh và đối với mỗi hợp đồng thuê được yêu cầu (trong phạm vi number_of_leases ), hợp đồng sẽ kiểm tra xem deposit_per_lease trong lệnh có lớn hơn deposit thấp nhất mà chủ sở hữu hợp đồng thuê hiện đang gửi hay không.

  • Tùy chọn Nhập Sau Xuất Trước (LIFO): Hợp đồng thông minh duy trì một danh sách có độ dài N , chứa các chủ sở hữu hợp đồng thuê dưới dạng (sender_ID, slot_entered) cho mỗi chủ sở hữu hợp đồng thuê. Đối với mỗi đơn hàng tương tác với hợp đồng thông minh và đối với mỗi hợp đồng thuê được yêu cầu, nếu deposit_per_lease lớn hơn min_deposit , chủ sở hữu hợp đồng thuê có slot_entered cao nhất sẽ bị xóa khỏi tập hợp và sender_ID của chủ sở hữu hợp đồng thuê mới sẽ được thêm vào tập hợp cùng với số slot hiện tại dưới dạng slot_entered .

• Truyền bá blob: Mỗi người giữ hợp đồng thuê có thể truyền bá một blob cho mỗi hợp đồng thuê mà họ nắm giữ trong mempool được phân mảnh theo chiều dọc.

Nếu hợp đồng thuê mempool được triển khai ngày nay, chúng ta có thể thấy Base duy trì hợp đồng thuê của họ cho một số slot liên tiếp. Các chuỗi khác không gửi blob thường xuyên như vậy (xem bảng Người gửi blob với thông tin "Trong 24 giờ qua ~🕰️ Giữa các blob" trong bảng điều khiển của hildobby ). Cơ chế thuê mempool có thể hoạt động tốt hơn khi thông lượng blob trên mỗi slot cao hơn nhiều so với hiện tại, ví dụ, sau khi thông lượng blob tăng gấp 8 lần, PeerDAS có thể sẽ ra mắt vào khoảng cuối năm 2025.

Cơ chế này có thể ảnh hưởng đáng kể đến hành vi của người gửi blob. Ngày nay, người gửi blob có xu hướng gửi một lượng lớn blob cùng lúc (ví dụ: 3 hoặc 6 blob cho mỗi khe cắm với thông lượng giới hạn 9 blob). Có thể, cơ chế cho thuê mempool sẽ yêu cầu người gửi blob gửi các blob mà họ vẫn còn giữ hợp đồng cho thuê. Nếu họ giữ 2 hợp đồng cho thuê, họ có thể gửi 2 blob trên 3 khe cắm thay vì 6 blob trong một khe cắm.

Hơn nữa, cơ chế cho thuê có thể mang lại lợi ích cho các chuỗi lớn hơn so với các chuỗi nhỏ. Các chuỗi nhỏ hơn có thể không có đủ thanh khoản để gửi một lượng lớn cổ phần để có được hợp đồng thuê mempool trong hệ thống dựa trên cổ phần, điều này sẽ ngăn cản họ sử dụng mempool được phân mảnh theo chiều dọc. Hệ thống LIFO có thể ưu tiên các chuỗi lớn hơn vì họ sẽ giữ hợp đồng thuê của mình mà không cần gửi các giao dịch đơn hàng mới. Lợi thế mà các chuỗi lớn có được từ điều này sẽ không đáng kể vì nó chỉ giúp họ tiết kiệm một khoản phí gas và khó có thể ảnh hưởng đến sự cạnh tranh giữa các L2 trong bức tranh toàn cảnh.

Vé Mempool đơn giản

Đề xuất này là đề xuất vé mempool đơn giản nhất, sử dụng giá niêm yết để bán một lượng vé mempool bằng với số lượng blob tối đa có thể được đưa vào khối. Cơ chế này bán vé trong mỗi slot.

Cơ chế hoạt động như sau:

• Mua: Các lệnh theo mẫu (sender_ID, number_of_tickets) được gửi đến hợp đồng thông minh ở bất kỳ vị trí nào.

• Phân bổ (tương tự như cơ chế Bán buôn) : Hợp đồng thông minh lấy đầu vào là các đơn hàng và xuất ra danh sách sender_ID và allocated_tickets tương ứng. Đối với mỗi đơn hàng tương tác với hợp đồng thông minh, nó sẽ phân bổ \\max(\\text{số lượng\\\_of\\\_tickets}, \\text{tickets\\_left}) m a x ( số tiếp theo​​​​​​​ _ của​ _ vé ,​​​​​​ văn bản vé​​​​​​​​ _ l e f t ) , trong đó tickets_left là biến bằng với hiệu số giữa tổng số vé và số vé đã phân bổ.

• Phát tán blob: Người giữ vé có thể phát tán một blob cho mỗi vé họ giữ.

Ưu điểm của đề xuất này là khả năng không cần cung vượt cầu ( k = 1) vì vé được mua trong mỗi khe. Do đó, có thể đặt ra giới hạn cứng về lượng băng thông cần thiết cho bộ nhớ blob trong mỗi khe, giúp tăng băng thông mà các nút có thể sử dụng cho các tác vụ khác.

Đề xuất này rất giống với đề xuất trước đây của Mike và Julian, sử dụng hình thức đấu giá theo giá đầu tiên. Ở đây, chúng tôi chuyển sang cơ chế niêm yết giá vì nó tiêu thụ ít xăng hơn.

Vé khách hàng thân thiết

Đề xuất này phân bổ ticket cho những người đã gửi blob gần đây. Mục tiêu là cung cấp ticket mempool cho những người gửi blob có nhiều khả năng gửi blob trong lần tiếp theo. Hình 1 (trích từ Bảng điều khiển Blob của Hildobby ) cho thấy Base sử dụng 43% blob, World Chain 24%, Arbitrum One 9% và rollups 24% còn lại.

hildobby_blobs 879×786 65,6 KB

Hình 1: Biểu đồ tròn về mức sử dụng blob cho thấy sự phân bố theo luật lũy thừa.

Cơ chế này có thể hoạt động như sau:

• Giám sát: Trong mỗi khe, hợp đồng thông minh lấy dữ liệu đầu vào là những người gửi blob (được lưu trữ dưới dạng sender_ID ) đã gửi blob trong khe trước đó. Hợp đồng thông minh duy trì trọng số cho một tập hợp sender_ID N N. Nó gán trọng số cho mỗi sender_ID như sau:

  • Cập nhật\_{i} = \\alpha \\frac{Blobs\_{i}}{Tổng \\text{ }Blobs} + (1 - \\alpha) Cũ \\text{ } Trọng lượng\ _ { i } Cập nhật _ i = một l p h a f r a c B l o b s _ i T o t a l chữ​​​ B l o b s + ( 1 − a l p h a ) Cũ​​ chữ​​​ W e i g h t _ i

  • Mới \\text{ } Trọng số\_{i} = \\frac{Cập nhật\_{i}}{\\sum\_{i \\in N} Cập nhật\_{i } } Mới chữ​​​ W e i g h t _ i = f r a c Cập nhật _ i​​​​ s u m _ i i n N U p d a t e _ i

  • Chúng ta có thể xem xét trọng số tối thiểu sao cho những người gửi blob được phân bổ nhận được ít nhất 3 vé vì những người gửi blob dường như gửi ít nhất 3 blob cho mỗi khối để khấu hao chi phí.

• Phân bổ: Trong mỗi khe, n vé được phân bổ cho tập hợp sender_ID N N tỷ lệ thuận với trọng số của chúng, làm tròn đến số nguyên gần nhất và giới hạn ở max_blobs . n có thể là bội số của số lượng blob tối đa có thể được gửi trong mỗi khe.

• Phát tán blob: Người giữ vé có thể phát tán một blob cho mỗi vé họ giữ.

Cơ chế này trông tương tự như cơ chế Thuê LIFO được mô tả ở trên. Cả hai đều cố gắng phân bổ vé cho những người có khả năng cần vé nhất trong khung thời gian tiếp theo. Tôi nghĩ cần phải mô phỏng bằng cách sử dụng hành vi hiện tại của trình gửi blob để hiểu đầy đủ sự khác biệt giữa hai cơ chế này.

Hơn nữa, Francesco đề xuất kết hợp cơ chế này với cơ chế Vé Mempool đơn giản để cho phép vào cửa miễn phí đồng thời tối đa hóa khả năng những người cần vé đã có vé.

Cuối cùng, các tham số sẽ cần được tinh chỉnh để giảm thiểu gánh nặng UX khi roll-up. Chúng ta cần mô phỏng để làm điều này. Vì hành vi của trình gửi blob có thể thay đổi đáng kể khi lưu lượng blob tăng lên, các tham số có thể cần được thay đổi, điều này có thể dẫn đến thay đổi trong hợp đồng thông minh.

Đấu giá ngoài giao thức và vé miễn phí

Để giảm chi phí gas của hệ thống, chúng tôi chuyển từ hệ thống đấu giá sang hệ thống niêm yết giá. Trong trường hợp tắc nghẽn, chúng tôi giả định rằng người gửi blob có thể gắn phí ưu tiên vào lệnh mua vé của họ và các nhà xây dựng sẽ đặt lệnh giao dịch với mức phí ưu tiên cao hơn so với các lệnh có mức phí ưu tiên thấp hơn.

Vì chúng tôi giả định các giao dịch trả phí ưu tiên cao hơn được bao gồm so với các giao dịch trả phí thấp hơn, nên chúng tôi không cần tính giá cho các vé. Kẻ tấn công muốn ngăn chặn các rollup đăng blob cần phải trả giá cao hơn các rollup muốn truyền bá blob của mình qua mempool được phân mảnh theo chiều dọc, bất kể giá vé. Tắc nghẽn sẽ cực kỳ hiếm và rất có thể do kẻ tấn công gây ra vì vé được cung cấp quá mức k đến số lượng blob tối đa và số lượng blob mục tiêu chỉ bằng 2/3 số lượng tối đa. Nói cách khác, nhu cầu tự nhiên sẽ phải cao gấp 15 lần so với dự kiến để gây tắc nghẽn (với k = 10).

Lưu ý rằng cuộc tấn công trong trường hợp xấu nhất sẽ ngăn chặn các roll-up sử dụng mempool được phân mảnh theo chiều dọc trong một khoảng thời gian. Các roll-up vẫn có thể sử dụng mempool xây dựng riêng hoặc calldata để đăng dữ liệu của chúng. Cuộc tấn công trong trường hợp xấu nhất rất tốn kém vì kẻ tấn công phải chịu chi phí để trả giá cao hơn các roll-up hoặc phải từ bỏ các khoản phí ưu tiên mà các roll-up sẵn sàng trả.

Vé miễn phí làm giảm sự phức tạp và do đó giảm chi phí xăng dầu của hệ thống vì không cần thiết phải đặt giá tối thiểu và không phải hoàn lại tiền .

Triển khai hợp đồng thông minh

Tất cả các đề xuất vé/cho thuê mempool nêu trên đều có thể được triển khai thông qua hợp đồng thông minh và không yêu cầu hard fork. Hợp đồng thông minh chọn một quy tắc phân bổ (ví dụ: Thuê Mempool LIFO hoặc Vé Mempool Đơn giản). Nó lấy các lệnh đầu vào và xuất ra danh sách sender_ID có thể truyền bá các blob trong mempool được phân mảnh theo chiều dọc. Sau đó, các nút sẽ lấy danh sách này và sử dụng nó trong lớp thực thi của mempool được phân mảnh theo chiều dọc.

Cuối cùng, việc phân mảnh theo chiều dọc mempool cũng không yêu cầu hard fork vì đây là một thay đổi ở cấp độ mạng. Các mempool phân mảnh theo chiều dọc đòi hỏi sự phối hợp xã hội vì người gửi blob phải phân mảnh các blob của họ để có thể lan truyền trong mempool phân mảnh theo chiều dọc.

Điều quan trọng là, vì việc phân bổ vé mempool sẽ được thực hiện thông qua hợp đồng thông minh, nên việc thay đổi tương đối dễ dàng. Giả sử hành vi của người gửi blob thay đổi, hợp đồng thông minh với quy tắc phân bổ vé mempool có thể được hoán đổi sang một quy tắc khác phù hợp hơn với hành vi mới.

So sánh với Sparse Blobpool và Horizontal Sharding

Trong phần này, chúng tôi so sánh mempool phân mảnh theo chiều dọc với các đề xuất phân mảnh theo chiều ngang và phân mảnh theo chiều dọc. Phần này giả định rằng bạn đã quen thuộc với các đề xuất phân mảnh theo chiều dọc, phân mảnh theo chiều dọc và phân mảnh theo chiều ngang.

Blobpool thưa thớt

Trong một blobpool thưa thớt, các nút tải xuống toàn bộ một blob với một xác suất nào đó (đề xuất: p = 0,15) và lấy mẫu theo cách khác (p = 0,85). Điều này có nghĩa là lượng dữ liệu dự kiến phải tải xuống cho mỗi blob là 0,15 + \\frac{0,85}{8} \\approx 25% 0,15 + f r a c 0,85 8 khoảng 25 % . Trong đề xuất mempool phân mảnh theo chiều dọc, chỉ có \\frac{1}{8} = 12,5% f r a c 1 8 = 12,5 . Do đó, mempool được phân mảnh theo chiều dọc sẽ giảm lượng băng thông mà các nút cần sử dụng trong mempool. Điều này đặc biệt quan trọng nếu hệ số phân mảnh (8 ở trên) tiếp tục tăng, điều này sẽ được thảo luận trong tương lai.

Một lợi thế của đề xuất blobpool thưa thớt là nó không làm thay đổi trải nghiệm người dùng của người gửi blob so với hiện trạng. Vé mempool thực sự thay đổi trải nghiệm người dùng. Các lần lặp lại tiềm năng của khái niệm vé mempool có thể thay đổi trải nghiệm người dùng theo hướng mà các rollup mong muốn , chẳng hạn như cố định giá blob trước.

Phân mảnh theo chiều ngang

Trong một mempool phân mảnh theo chiều ngang , trình xác thực sử dụng một quy tắc để xác định xem có nên tải xuống toàn bộ blob hay không. Ưu điểm là mempool phân mảnh theo chiều ngang có thể dễ dàng triển khai vì không cần hệ thống ticket để ngăn chặn các cuộc tấn công DoS. Nhược điểm là băng thông được sử dụng cho mỗi nút trên mỗi slot có độ biến thiên cao, vì trong một số slot, trình xác thực có thể cần tải xuống nhiều blob, trong khi một số slot khác thì không.

Điều quan trọng là, một mempool được phân mảnh theo chiều dọc ngăn chặn các trình xác thực thực hiện công việc trùng lặp vì chúng có thể tải xuống các mẫu cho các blob mà chúng thấy trong mempool lớp thực thi và không phải tải xuống lại chúng trên lớp đồng thuận khi khối đến (giả sử nhắn tin ở cấp độ tế bào). Trong một mempool được phân mảnh theo chiều ngang, các trình xác thực sẽ làm thêm việc vì chúng tải xuống các phần blob mà chúng không cần trong mempool lớp thực thi và sau đó cần tải xuống các mẫu trong lớp đồng thuận khi khối đến. Mặc dù trong FullDAS, các trình xác thực có thể được yêu cầu lưu giữ các blob đầy đủ thay vì chỉ lưu giữ các mẫu trong PeerDAS, nhưng PeerDAS là công nghệ đang được triển khai và hiện chưa rõ khi nào FullDAS có thể đến.

Phần kết luận

Việc cải thiện mempool blob là ưu tiên hàng đầu vì mempool hiện tại không thể duy trì được sự gia tăng lớn về số lượng blob mà Ethereum có thể sớm chứng kiến. Phân mảnh mempool theo chiều dọc là một giải pháp hấp dẫn vì nó giảm đáng kể băng thông cần thiết cho mempool và ngăn ngừa việc trùng lặp công việc trên lớp đồng thuận để thực hiện lấy mẫu dữ liệu quan trọng về tính khả dụng của đồng thuận.

Vấn đề chính khi triển khai mempool phân mảnh theo chiều dọc là cần phải có một cơ chế phòng ngừa DoS. Trong bài viết này, chúng tôi đề xuất ba cơ chế vé mempool giúp ngăn chặn DoS đồng thời cho phép mempool phân mảnh theo chiều dọc. Sự đánh đổi chính nằm ở việc ảnh hưởng đến trải nghiệm người dùng và lượng gas cần thiết để vận hành cơ chế này. Bảng 1 tóm tắt các đặc điểm của các đề xuất trong bài viết này.

Bảng 1: Tóm tắt các đặc tính về khí đốt và trải nghiệm người dùng của các đề xuất Vé bán buôn, Hợp đồng thuê Mempool (Cổ phần và LIFO) và Vé Mempool đơn giản.

Điều quan trọng là cơ chế ticket có thể được thay đổi tương đối dễ dàng nếu cần vì chúng được triển khai thông qua hợp đồng thông minh và không yêu cầu thay đổi giao thức. Điều này đặc biệt quan trọng vì ticket mempool không chỉ thay đổi trải nghiệm người dùng của người gửi blob mà còn làm tăng đáng kể lưu lượng mà chúng ta sẽ sớm thấy. Tác động của sự tương tác giữa việc tăng lưu lượng và ticket mempool lên trải nghiệm người dùng là rất khó dự đoán, vì vậy tính linh hoạt của cơ chế ticket mempool là rất cần thiết.