Chuyển tiếp Tiêu đề gốc：Cơ chế phí giao dịch Solana & Ethereum: Đề xuất cải thiện TFM của Solana

Cảm ơn Andrew Fitzgerald, Harsh Patel, Jon Charbonneau, Kevin Galler, Lanre Ige, Mert Mumtaz, Pranav Garimidi, Ryan Chern, Tao Zhu và Tarun Chitra vì những phản hồi và đánh giá.

Giới thiệu loại coin

Eclipse là SVM L2 đầu tiên của Ethereum. Chúng tôi vô cùng vui mừng được mang sức mạnh của SVM hiện tại đến với nhiều người dùng hơn, nhưng chúng tôi cũng tận tâm thúc đẩy hoạt động R&D đang diễn ra xung quanh chính SVM. Chúng tôi tập trung vào việc đảm bảo rằng sự phát triển của Eclipse chắc chắn sẽ trả lại giá trị cho tất cả các chuỗi SVM, đặc biệt là Solana.

Là tiền đề cho các bài viết trong tương lai về suy nghĩ của chúng tôi về thị trường phí, bài viết này sẽ phân tích thị trường phí hiện tại của Solana và các đề xuất liên quan để cải thiện nó. Chúng tôi đóng khung các đề xuất này cùng với các mục tiêu lý thuyết chính cho bất kỳ Cơ chế phí giao dịch (TFM) nào, vay mượn rất nhiều từ công trình của Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi và những người khác. Chúng tôi sẽ chỉ ra các định nghĩa cốt lõi xuyên suốt bằng **.

Nói chung, TFM xác định:

1. Những giao dịch nào được bao gồm trong một khối nhất định,
2. Các khoản phí mà một giao dịch nhất định phải trả và
3. Phí giao dịch tích lũy được phân phối như thế nào (và cho ai).

Cuối cùng, bài viết này nhằm mục đích kết hợp sự phong phú của nghiên cứu TFM tập trung vào Ethereum với kỹ thuật đổi mới của Solana.

Tổng quan về TFM hiện tại của Solana & Ethereum

Khái niệm cơ bản về Solana so với Ethereum

Chúng ta sẽ bắt đầu với cái nhìn tổng quan về TFM của Solana và so sánh nó với TFM của Ethereum. Điều này sẽ bối cảnh hóa tốt hơn các đề xuất liên quan để chúng tôi có thể nỗ lực sửa đổi và cải thiện TFM. Cho người mới bắt đầu:

Phí cơ bản của Solana là 5.000 lamport cố định (0,000005 SOL) cho mỗi chữ ký và hầu hết các giao dịch đều có một chữ ký. Nó không tính đến tài nguyên tính toán rộng hơn của giao dịch (được đo bằng CU).

Phí cơ sở Solana Tx = (5.000 Lamport) x (# chữ ký trong Tx)

Cơ chế phí cơ bản của Ethereum khác nhau theo hai cách chính:

1. Năng động - Phí cơ bản của Ethereum (được đo bằng gwei trên mỗi đơn vị gas) thả nổi dựa trên nhu cầu thị trường.
2. Phí chi tiết hơn trên mỗi đơn vị tính toán - Phí cơ sở cho mỗi giao dịch của Ethereum là tuyến tính theo lượng gas tiêu thụ.

Vì vậy, phí cơ sở cho mỗi giao dịch của Ethereum là:

Phí cơ sở Ethereum Tx = (Giá gas hiện hành tính bằng gwei) x (gas được sử dụng tính bằng tx)

Người dùng Solana cũng có thể thêm phí ưu tiên tùy chọn để cải thiện khả năng được đưa vào. Không giống như phí cơ bản, phí ưu tiên được tính theo CU được yêu cầu cho một giao dịch. Các giao dịch Solana có thể bao gồm các hướng dẫn Tính toán ngân sách sau:

1. SetComputeUnitLimit - Giao dịch có thể đặt số lượng CU tối đa mà chúng được phép tiêu thụ (tối đa là 1,4 triệu CU cho mỗi giao dịch). Khi được thực hiện, giao dịch có thể sử dụng tối đa giới hạn CU được yêu cầu. Nếu không có lệnh SetComputeUnitLimit nào được cung cấp thì giới hạn CU của giao dịch được tính bằng (# lệnh trong giao dịch) x (200k CUs).
2. SetComputeUnitprice - Số lượng micro-lamport trên mỗi CU đã yêu cầu giao dịch đề nghị thanh toán phí ưu tiên.

Đặt chúng lại với nhau:

Phí ưu tiên Tx = (Giới hạn Tx CU) x (Giá CU)

Lưu ý rằng phí ưu tiên này được thanh toán dựa trên toàn bộ CU được yêu cầu (bất kể giao dịch có sử dụng tổng số tiền được yêu cầu hay không), không giống như trong Ethereum, trong đó phí là hàm số của lượng gas mà giao dịch thực sự sử dụng.

Phí đốt so với phần thưởng của người xác thực

Mặc dù động cơ khuyến khích người xác nhận ưu tiên các giao dịch có phí cao nằm ngoài sự đồng thuận, nhưng nó được thực thi theo sự đồng thuận rằng cả phí cơ bản và phí ưu tiên đều là 50/50 được đốt/gửi cho người đứng đầu (nhà sản xuất khối hiện tại) ở Solana:

1. Phí cơ bản — Bắt buộc để bao gồm khối. Các giao dịch thiếu phí cơ bản cần thiết sẽ bị từ chối.
2. Phí ưu tiên - Không bắt buộc để bao gồm khối. Được sử dụng để tùy chọn ưu tiên các giao dịch muốn tăng khả năng đưa vào nhanh chóng.

Người dùng không thể tránh phải trả phí cơ bản, nhưng người ta có thể tránh phí ưu tiên và báo hiệu mong muốn được ưu tiên theo cách khác. Chúng tôi đã thấy điều này trong thực tế - các cuộc đấu giá Jito-Solana trả 100% (ít phí hơn) cho người dẫn đầu ngoài nhóm. SIMD-0096 đưa ra cách khắc phục đơn giản cho vấn đề này, thưởng 100% phí ưu tiên cho người xác nhận.

Chuyển khoản trực tiếp*: Phối hợp thông qua đấu giá MEV-Boost / Jito-Solana

Điều quan trọng là người xác thực Solana bỏ phiếu cho từng khối với các giao dịch trực tuyến. Họ trả phí cơ bản cho mỗi giao dịch này.

Solana gần đây đã đạt mức phí mạng cao nhất mọi thời đại, nhờ phí ưu tiên tăng mạnh. Việc phân chia phí gần đây được hiển thị dưới đây:

Nguồn: La bàn Solana

Trình tạo khối Ethereum so với Trình lập lịch Solana

Quá trình sản xuất khối của Ethereum nhìn chung dễ hiểu hơn nên chúng ta sẽ bắt đầu từ đó. Gần như tất cả các trình xác nhận (còn gọi là người đề xuất) thuê ngoài việc sản xuất khối cho những người xây dựng ngoài giao thức thông qua MEV-Boost. Các nhà xây dựng tạo các khối cứ sau 12 giây (thời gian của Ethereum) và chuyển toàn bộ các khối này cho người đề xuất (thông qua rơle), người chọn khối có giá trị cao nhất.

Trong cả Ethereum và Solana, các nhà sản xuất khối đều có quyền ra lệnh giao dịch tùy ý trong một khối. Họ được khuyến khích làm như vậy theo cách tối đa hóa lợi nhuận của họ. Ví dụ: các nhà xây dựng Ethereum khác nhau có thể cạnh tranh bằng cách chạy các thuật toán độc quyền nhằm tối đa hóa lợi nhuận hiệu quả hơn so với các đối thủ cạnh tranh.

Điều này có nghĩa là ngay cả trong Ethereum, việc gửi một khoản phí ưu tiên cao cũng không đạt được bất kỳ đảm bảo xác định nào trong giao thức về việc đưa vào hoặc đặt hàng khối. Tuy nhiên, rất có khả năng đạt được kết quả như mong đợi do bản chất của quy trình xây dựng khối hiện tại của Ethereum, trong đó người xây dựng xây dựng một khối tối đa hóa lợi nhuận đầy đủ ở cuối mỗi vị trí riêng biệt.

Ví dụ: người tìm kiếm có thể gửi giao dịch chênh lệch giá với mức phí ưu tiên cực kỳ cao (ví dụ: cao hơn tất cả các giao dịch đủ điều kiện khác cộng lại) tới người xây dựng, yêu cầu đưa giao dịch đó vào đầu khối và loại trừ hoàn toàn giao dịch khỏi khối nếu nó không đạt được vị trí cao nhất. Trong trường hợp này, người xây dựng tối đa hóa lợi nhuận hợp lý sẽ đưa giao dịch này vào đầu khối ngay cả khi họ chỉ nhận được nó ngay khi kết thúc khoảng thời gian 12 giây của mình.

Bạn sẽ lưu ý rằng có hai đảm bảo khác nhau mà các khoản phí đang cố gắng đạt được ở đây:

1. Bao gồm - Người dùng muốn đưa giao dịch của họ vào khối này, nhưng họ không quan tâm giao dịch đó nằm ở đâu trong khối.
2. Đặt hàng - Người dùng không chỉ muốn được đưa vào khối ở bất kỳ đâu; họ muốn quyền truy cập ưu tiên vào một trạng thái cụ thể tại một thời điểm nhất định.

Cơ chế EIP-1559 của Ethereum đã được chứng minh là khá hiệu quả trong việc cho phép người dùng dễ dàng đấu thầu để đưa khối vào với xác suất thành công cao. Có một mức giá khởi điểm toàn cầu mà mọi người đều biết phải trả và việc trả nó (thường cùng với một khoản phí ưu tiên danh nghĩa) sẽ nhanh chóng đưa giao dịch của người dùng vào. Tuy nhiên, cơ chế này không tìm cách cung cấp bất kỳ sự đảm bảo nào xung quanh việc đặt hàng (tức là quyền truy cập ưu tiên vào trạng thái), trong khi các cơ chế ngoài giao thức lại đáng tin cậy đối với những người dùng đang tìm kiếm sự đảm bảo như vậy (ví dụ: trực tiếp từ các nhà xây dựng).

Quá trình xây dựng khối của Solana hoạt động rất khác. Người xác thực không thuê ngoài việc sản xuất toàn bộ khối trong các khoảng thời gian riêng biệt cho những người xây dựng ngoài giao thức. “Trình lập lịch biểu” là thuật toán mặc định có trong ứng dụng khách trình xác thực Solana Labs, giúp lên lịch thực hiện các giao dịch và xây dựng các khối liên tục.

Ngoài ra, các giao dịch Solana chỉ định những tài khoản nào phải được khóa đọc và ghi để thực thi. Điều này cho phép bộ lập lịch sắp xếp lặp đi lặp lại những giao dịch nào có thể được thực hiện đồng thời - vì các giao dịch không chạm vào cùng một trạng thái có thể được thực hiện song song.

Trong một khối, có thể sử dụng tối đa 12.000.000 CU để ghi tuần tự vào một tài khoản (“một phần trạng thái”). Đây gần bằng số lượng CU có thể được xử lý bởi một luồng đơn trên mỗi khe 400ms theo yêu cầu nút hợp lý. Giới hạn mỗi khối của Solana khi đó là 48.000.000 CU. Việc triển khai bộ lập lịch hiện tại sử dụng bốn luồng cho các giao dịch không bỏ phiếu và 12M x 4 = 48M. Về lý thuyết, điều này có nghĩa là sử dụng nhiều lõi hơn = tăng giới hạn CU. Mở rộng quy mô bằng phần cứng.

Bộ lập lịch ưu tiên không xác định các giao dịch có mức phí ưu tiên cao hơn. Tuy nhiên, điều này thường cung cấp các đảm bảo ưu tiên kém tin cậy hơn so với các cơ chế như các cơ chế được mô tả trong trường hợp Ethereum ngày nay.

Trong Solana, trình xác thực chạy các khối xây dựng bộ lập lịch mặc định liên tục, do đó, các giao dịch có thể được thêm vào khối đang diễn ra và được thực thi trước khi đợi cho đến khi hết thời gian để sắp xếp chúng chỉ theo phí ưu tiên. Mục đích là để người lập lịch trình tối đa hóa lợi nhuận một cách gần đúng bằng cách ưu tiên các giao dịch dựa trên tổng giá CU của chúng.

Bộ lập lịch đa luồng mặc định của Solana cũng giới thiệu thêm “jitter”. Các giao dịch được chỉ định ngẫu nhiên cho một trong bốn luồng, trong đó mỗi luồng duy trì hàng giao dịch riêng đang chờ thực thi. Phí ưu tiên sau đó được sử dụng để ưu tiên các giao dịch nội bộ. Tuy nhiên, chúng không giúp ưu tiên các giao dịch liên luồng.

Ví dụ: hai người tìm kiếm, mỗi người có thể gửi một giao dịch đồng thời để nắm bắt cùng một cơ hội kinh doanh chênh lệch giá và người gửi mức phí ưu tiên thấp hơn thậm chí có thể giành chiến thắng vì họ tình cờ rơi vào hàng đợi ít bị tắc nghẽn hơn. Điều này làm giảm hiệu quả của phí ưu tiên và tăng động lực gửi thư rác so với Ethereum - đặc biệt vì việc đưa vào các giao dịch cũng phụ thuộc vào thời điểm, trong một vị trí nhất định, giao dịch được chuyển đến nhà sản xuất khối hiện tại.

Lưu ý rằng có những thay đổi đã được lên kế hoạch đối với bộ lập lịch mặc định của Solana, nhằm giải quyết một số vấn đề với quá trình triển khai hiện tại bằng cách dựa vào biểu đồ phụ thuộc giao dịch và lập lịch cho các giao dịch được bỏ chặn (không bị khóa ghi) có mức ưu tiên cao nhất trong biểu đồ — chúng tôi đề cập đến điều này sau trong bài viết.

Mặc dù hầu như nằm ngoài phạm vi của bài viết này, ứng dụng khách Jito-Solana cho phép người tìm kiếm nắm bắt giá trị khai thác/giá trị có thể trích xuất tối đa (MEV) hiệu quả hơn theo cách giảm thiểu các tác động bên ngoài tiêu cực trên Solana. Jito-Solana khác với bộ lập lịch mặc định của Solana bằng cách giới thiệu các phiên đấu giá gói Flashbots-esque rời rạc ngoài giao thức 200 mili giây, được chạy song song với quá trình sản xuất khối liên tục mặc định và một mempool riêng (một lần nữa khác với TFM mặc định của Solana). Việc các trình xác thực Solana áp dụng ứng dụng khách Jito-Solana (>50% trình xác thực chạy ứng dụng này ngày nay) đã giúp giải quyết một số vấn đề với TFM hiện tại của Solana - cụ thể là sự phổ biến của thư rác do MEV điều khiển.

Những tồn tại của TFM hiện tại của Solana

Mặc dù TFM của Solana rất hứa hẹn nhưng hiện tại nó cũng có một số nhược điểm tiềm ẩn:

Khuyến khích thư rác

Như đã đề cập ở trên, các giao dịch được sắp xếp theo kiểu nhập trước, xuất trước (FIFO) ngay khi chúng đến tay nhà sản xuất khối. Ngoài ra, chúng còn phải tuân theo tính chất không xác định từ cả hiện tượng biến động mạng và phân bổ luồng ngẫu nhiên của bộ lập lịch mặc định. Mặc dù phí ưu tiên có thể giúp xác suất đưa vào trong một số trường hợp nhất định, nhưng động cơ đáng kể vẫn tồn tại đối với các giao dịch spam nhằm tối đa hóa xác suất đưa vào nhanh nhất (ví dụ: người tìm kiếm chạy đua để thanh lý vị thế mặc định trên thị trường cho vay). Hình ảnh dưới đây của Jito Labs giúp chứng minh tính chất chưa tối ưu của các giao dịch thư rác.

Nguồn: Quỹ Jito

Đấu giá theo giá đầu tiên

Trong phiên đấu giá theo giá đầu tiên (FPA) đơn giản, người dùng chỉ cần gửi giá thầu, giá thầu cao nhất sẽ được đưa vào khối. Một vấn đề với FPA là chúng không thân thiện với người dùng. Ví dụ: người dùng phải đoán những gì người dùng khác đang đặt giá thầu, suy nghĩ về những gì họ sẵn sàng đặt giá thầu, có khả năng giảm giá thầu của họ xuống thấp hơn để không trả quá cao dựa trên những gì họ tin rằng người khác đang đặt giá thầu.

Chính thức hơn, mô hình FPA không phải là DSIC:

**Tương thích khuyến khích chiến lược thống trị (DSIC): Giả sử rằng nhà sản xuất khối triển khai TFM một cách trung thực, thì chiến lược đặt giá thầu được quy định sẽ là chiến lược thống trị cho người dùng. Điều này có nghĩa là người dùng sẽ đặt giá thầu (bằng phí giao dịch) với giá trị chính xác mà họ quy định cho việc bao gồm giao dịch [Chu22].

DSIC là một trong những thuộc tính quan trọng mà những người tạo ra EIP-1559 muốn đưa vào TFM của Ethereum khi triển khai nó và như chúng tôi đã mô tả trước đó, nó có thể được coi là một thành công. Người dùng dễ dàng biết giá dự trữ công cộng sẽ được đưa vào khối tại một thời điểm nhất định (thông qua phí cơ sở động), do đó, việc thanh toán giá đó (cộng với bất kỳ khoản phí ưu tiên danh nghĩa nào) hầu như sẽ luôn giúp giao dịch của bạn được đưa vào nhanh chóng.

Ngược lại, TFM của Solana là một FPA ngây thơ. Nó thiếu một cơ chế đáng tin cậy để người dùng thể hiện chính xác sở thích của họ đối với việc đưa vào khối và không phải là DSIC. Trong thực tế, việc cố gắng đặt chính xác mức phí ưu tiên phù hợp vào đúng thời điểm là một thách thức vô cùng lớn. Điều này đặc biệt có lợi cho những người tham gia tinh vi , những người có khả năng vượt qua jitter mạng và bộ lập lịch nhiều hơn (ví dụ: thông qua các giao dịch cùng vị trí hoặc gửi thư rác).

50/50 Ghi/Xác nhận thanh toán

Như đã lưu ý trước đó, Ethereum đốt 100% phí cơ sở trong khi gửi 100% phí ưu tiên cho nhà sản xuất khối, trong khi đối với Solana, cả phí cơ sở và phí ưu tiên đều là 50/50 được đốt/trả cho nhà sản xuất khối. Do đó, Solana TFM không chứng minh được OCA:

**Khả năng chứng minh thỏa thuận ngoài chuỗi (OCA-proofness hoặc SCP): Không có thỏa thuận ngoài chuỗi nào giữa người dùng và nhà sản xuất khối có thể Pareto cải thiện kết quả của TFM cho một khối nhất định [Rou21]. Giao thức c-SCP chống lại liên minh của nhà sản xuất khối và tối đa người dùng c có thể kiếm lợi bằng cách đi chệch khỏi việc báo cáo trung thực.

Chúng tôi thấy một ví dụ rõ ràng về điều này với các cuộc đấu giá ngoài giao thức của Jito-Solana thanh toán 100% giá thầu (ít hơn phần cắt của Jito) cho các nhà sản xuất khối, thay vì đốt 50% - Jito-Solana là một ví dụ về Off-Chain Thỏa thuận được sử dụng bởi các nhà sản xuất khối. Tuy nhiên, chúng tôi lưu ý rằng tiền boa của Jito-Solana không tương đương với phí ưu tiên, vì phí ưu tiên chỉ được thanh toán nếu giao dịch liên kết (và gói) thực hiện thành công.

SIMD-0109 được đề xuất gần đây sẽ đưa cơ chế tới hạn (tương tự như cơ chế được sử dụng trong đấu giá ngoài giao thức của Jito-Solana) vào giao thức dưới dạng hướng dẫn gốc.

Thiếu các loại giao dịch đặc quyền

Các giao dịch bỏ phiếu của Solana được đăng trên chuỗi và phải được đưa vào các khối, tuy nhiên mỗi người xác thực phải thanh toán chi phí cho các giao dịch nói trên. Điều này thể hiện một chi phí cố định đáng kể (được thanh toán riêng bởi những người xác nhận) mặc dù có tác động bên ngoài tích cực của việc bao gồm các giao dịch phiếu bầu. Chi phí này càng trở nên trầm trọng hơn do thực tế là các giao dịch bỏ phiếu bị tính phí quá cao so với số CU được tiêu thụ (tức là chúng sử dụng tương đối ít CU so với giao dịch trung bình). Kinh tế tạo ra hiệu ứng tập trung ở đây, vì tổng chi phí bỏ phiếu gần như không đổi đối với bất kỳ người xác nhận nào trong khi phần thưởng kiếm được tỷ lệ thuận với trọng lượng cổ phần.

Nguồn: Ceteris, Solana the Monolith

Ngoài ra, logic tương tự có thể được mở rộng để bao gồm các bản cập nhật oracle đáng tin cậy, mà các mạng thường tính phí bất chấp tác động bên ngoài tích cực của nguồn cấp dữ liệu giá chính xác trên chuỗi. Một chuỗi có nhiều quan điểm hơn nhận được giá trị cao từ một nhà tiên tri mạnh mẽ cụ thể có thể chọn áp dụng một cơ chế trợ cấp chi phí của nó.

Thị trường phí địa phương của Solana

Cơ chế phí địa phương gần đúng của Solana tồn tại vì không tài khoản nào có thể ghi nhiều hơn 12 triệu CU trên mỗi giới hạn khối 48 triệu. Điều này, cùng với tính chất đa luồng của bộ lập lịch mặc định của Solana, có nghĩa là tối đa 25% giao dịch trong một khối có thể tương ứng với một phần trạng thái theo yêu cầu. Về lý thuyết, người dùng ở trạng thái ít có nhu cầu hơn không cần phải tăng phí ưu tiên để có được sự đảm bảo hòa nhập mạnh mẽ so với người dùng ở trạng thái có nhu cầu cao hơn.

Đây được cho là không phải là một cơ chế phí địa phương thực sự. Cơ chế này không được thực thi bằng sự đồng thuận (nó chỉ ở cấp độ người lập lịch) và mối quan hệ giữa phí ưu tiên và việc đưa vào khối là không mang tính quyết định (như đã đề cập trước đó). Nó cũng thiếu khái niệm về 'độ co giãn' khi tồn tại cả giới hạn tài nguyên mục tiêu và tài nguyên tối đa.

Yêu cầu và sử dụng CU không hiệu quả

Vì phí cơ sở của Solana không tính đến CU nên nó không khuyến khích các giao dịch:

1. Sử dụng CU hiệu quả — Một giao dịch có 1,4 triệu CU có cùng mức phí cơ bản như một giao dịch có 100 nghìn CU, tất cả các yếu tố khác đều bằng nhau.
2. Yêu cầu CU hiệu quả — Ngay cả khi giao dịch sử dụng 50 nghìn CU, giao dịch đó vẫn có cùng mức phí cơ bản cho dù yêu cầu 100 nghìn CU hay 1 triệu CU.

Điều này có thể dẫn đến việc bộ lập lịch đánh giá quá cao lượng điện toán cần thiết trong một khối nhất định và làm giảm hiệu quả so với các tài nguyên mà nhà sản xuất khối yêu cầu tại một vị trí nhất định. DSIC TFM sẽ khắc phục vấn đề này vì chiến lược chủ đạo của người dùng sẽ là chiến lược đặt giá thầu được quy định — trong trường hợp này, thể hiện chính xác mức sử dụng CU dự kiến.

Không tốn kém khi ghi tài khoản khóa

Như đã đề cập trước đó, các giao dịch Solana chỉ định trước tất cả các tài khoản mà chúng sẽ đọc hoặc ghi vào trong khi thực hiện. Tuy nhiên, ngày nay cơ chế này có thể bị lạm dụng để khóa bất kỳ tài khoản nào trên toàn cầu mà không mất phí. Ví dụ:

1. Tôi gửi Tx_A trong đó chỉ định rằng nó sẽ ghi vào Tài khoản_A.
2. Người lãnh đạo nhận được Tx_A, lên lịch và bắt đầu thực hiện nó. Tài khoản_A hiện đã bị khóa - không có giao dịch nào khác chạm vào Tài khoản_A có thể được thực hiện cho đến khi Tx_A thực hiện xong.

Vấn đề bắt nguồn từ thực tế là bất kỳ ai cũng có thể gửi các giao dịch ghi khóa bất kỳ tài khoản nào họ muốn. Việc khóa tài khoản không mất phí và các giao dịch thậm chí có thể khóa các tài khoản mà họ không sử dụng, đây rõ ràng là một phương tiện tấn công thư rác. Hơn nữa, chủ tài khoản không có quyền kiểm soát ai có thể khóa tài khoản của chính họ.

Đề xuất & Khung TFM

Cuối cùng, mọi blockchain phải quyết định cách phân bổ nguồn tài nguyên khan hiếm của không gian khối hữu hạn giữa những người dùng, điều này thực hiện thông qua TFM của nó. Dưới đây, chúng tôi sẽ thảo luận về một số đề xuất và khuôn khổ TFM có liên quan có thể có giá trị đối với Solana.

Thị trường phí Blockchain đa chiều

Hầu hết các thị trường phí hiện tại đều là một chiều, được xây dựng xung quanh một đơn vị tài khoản có thể thay thế được (ví dụ: gas trong Ethereum). Tuy nhiên, tài nguyên duy nhất được mua này là proxy cho nhiều tài nguyên cơ bản không thể thay thế được (ví dụ: băng thông, tính toán và lưu trữ).

Ví dụ: mỗi opcode Ethereum mang một lượng gas cố định nhất định mà nó tiêu thụ (ví dụ: ADD sử dụng 3 gas, trong khi MUL sử dụng 5 gas). Giá gas cho mỗi opcode được đặt dưới dạng xấp xỉ gần đúng của các tài nguyên cơ bản mà chúng sử dụng và mức độ đắt đỏ của những tài nguyên đó đối với các nút trong mạng. Ví dụ: thước đo ngầm này về chi phí vận hành có thể được xác định bằng cách chạy điểm chuẩn trên phần cứng trong thế giới thực.

Tuy nhiên, cũng có thể xây dựng các thị trường phí đa chiều định giá riêng lẻ các tài nguyên không thể thay thế khác nhau này thay vì kết hợp chúng thành một đơn vị. EIP-4844 là một thị trường phí hai chiều đơn giản, vì các khối dữ liệu có thị trường phí riêng độc lập với khí thực thi Ethereum.

Bài báo năm 2022 này của Diamandis, Evans, Chitra và Angeris phân tích cách xây dựng các thị trường phí đa chiều như thế này. Công việc của họ giải quyết vấn đề xây dựng TFM từ quan điểm của một nhà thiết kế mạng nhằm tối đa hóa phúc lợi (hoặc tổng tiện ích) của người dùng chuỗi khối trừ đi mức tiêu thụ tài nguyên của những người dùng nói trên, tùy thuộc vào các ràng buộc về giao dịch và khối của chuỗi (ví dụ: giới hạn hợp đồng thông minh hoặc giới hạn CU/gas). Kết quả chính của bài báo là mặc dù phúc lợi chưa được biết đến nhưng họ đã thiết kế một cơ chế tối đa hóa nó và chỉ ra cách xây dựng cơ chế nói trên một cách rõ ràng.

**Tối đa hóa phúc lợi: Các quy tắc phân bổ và thanh toán dự kiến ngụ ý rằng tổng thặng dư của người tiêu dùng và thợ mỏ được (xấp xỉ) tối đa hóa.

Phát hiện quan trọng của họ là có thể triển khai một TFM tương đương, đó là một trong đó giá tài nguyên được đặt để giảm thiểu sự khác biệt giữa phúc lợi của người xác nhận và người dùng của nó - mức giá như vậy sẽ dẫn đến các khối mà theo lý thuyết là tối ưu so với phúc lợi. -Tối đa hóa quan điểm. Mặc dù công việc này có thể được coi là một khuôn khổ học thuật để thiết kế các TFM tối ưu, nhưng nó giúp cho thấy rằng các tài nguyên định giá riêng biệt có thể làm cho chuỗi khối hiệu quả hơn và linh hoạt hơn trước các giai đoạn tắc nghẽn hoặc spam cao. Các cơ chế phí cơ sở dựa trên bộ điều khiển, chẳng hạn như EIP-1559, được đánh dấu là một phương pháp tiếp cận tiềm năng có thể hoạt động cực kỳ tốt trên chuỗi Solana và SVM, với thời gian chặn ngắn, cho phép phí cơ sở điều chỉnh nhanh chóng theo những thay đổi về nhu cầu và tài nguyên của người dùng khả dụng.

Như đã đề cập trước đó, một kết luận từ bài báo là có thể thiết kế các cách hiệu quả về mặt tính toán và có hệ thống để giúp xác định và cập nhật giá của các tài nguyên đa chiều cho chuỗi khối. Tuy nhiên, một câu hỏi tự nhiên nên là: nguồn tài nguyên nào sẽ hợp lý để định giá rõ ràng? Một số công việc thực tế đã được thực hiện trong các bối cảnh blockchain khác để đưa ra những quyết định như vậy. Ví dụ: Penumbra đã triển khai một hình thức định giá tài nguyên đa chiều để định giá các tài nguyên được sử dụng bởi các nút đầy đủ và thiết bị người dùng cuối một cách riêng biệt trên chuỗi khối tập trung vào quyền riêng tư của họ.

Mặc dù bài viết năm 2022 thường thảo luận về việc định giá tài nguyên cơ sở theo nhiều chiều (ví dụ: điện toán, băng thông, lưu trữ), nhưng cũng có thể triển khai định giá tài nguyên đa chiều cho mỗi tài khoản (tức là theo “phần trạng thái”). Mỗi tài khoản được coi là một tài nguyên khác nhau. Điều này được thảo luận trong bài viết gần đây này, được xây dựng dựa trên bài báo gốc. Các tài khoản định giá riêng lẻ (thay vì tính toán, lưu trữ, băng thông, v.v.) làm tài nguyên cơ bản cũng có thể dễ triển khai hơn và giảm nguy cơ xảy ra các cuộc tấn công cạn kiệt tài nguyên.

Phí lũy thừa cho tài khoản ghi khóa

Sau bài đăng gần đây của Anatoly về Kinh tế thực thi SVM, Tao Zhu, cộng tác với Anatoly, đã đề xuất SIMD-0110. Động lực chính của nó là ngăn chặn thư rác với áp lực kinh tế ngược (tức là tăng phí theo cách có mục tiêu theo thời gian để giảm động cơ gửi thư rác), dẫn đến việc sử dụng tài nguyên mạng hiệu quả hơn. Các giao dịch chênh lệch giá không thành công tiếp tục chiếm khoảng một nửa (hoặc nhiều hơn) không gian khối của Solana vì việc gửi thư rác là hợp lý và cực kỳ rẻ.

Đề xuất khuyến nghị theo dõi Đường trung bình động hàm mũ (EMA) của việc sử dụng CU của mỗi tài khoản trên mỗi khối để đạt được điều này. Chi phí để ghi khóa một tài khoản sẽ tăng theo cấp số nhân dựa trên việc sử dụng CU tương ứng của tài khoản đó, ngăn chặn thư rác. Logic cốt lõi tương tự như cách EIP-1559 đặt phí cơ sở toàn cầu của Ethereum như một chức năng sử dụng gas trong các khối kéo dài. Tuy nhiên, SIMD này chi tiết hơn nhiều trong việc thiết lập thị trường phí cơ sở địa phương cho mỗi tài khoản.

Ý tưởng triển khai cơ bản cho phí khóa ghi khác nhau dựa trên tài khoản sẽ như sau:

1. Theo dõi việc sử dụng đơn vị tính toán EMA của từng tài khoản gây tranh cãi trong 150 vị trí vừa qua.
2. Số lượng tài khoản tối đa sẽ được theo dõi là 2048, trong đó chỉ những tài khoản gây tranh cãi nhất có tỷ lệ chi phí khóa ghi cao nhất mới được theo dõi.
3. Nếu mức sử dụng đơn vị tính toán EMA của tài khoản >50% giới hạn CU tối đa thì tỷ lệ chi phí khóa ghi của tài khoản đó sẽ tăng X%. Nếu <50% giới hạn, tỷ lệ chi phí sẽ giảm X%.
4. V0 đề xuất mức chi phí khóa ghi ban đầu là 1000 micro-lamport/CU và mức điều chỉnh mức chi phí là 1% cho mỗi khe cắm (lưu ý rằng tỷ lệ phần trăm chính xác ở đây đều có thể thay đổi do tính chất ban đầu của đề xuất).
5. Phí khóa ghi cho một tài khoản tại một khối nhất định được tính bằng cách nhân tỷ lệ chi phí khóa ghi với CU được yêu cầu của giao dịch.
6. Các giao dịch tiếp tục phải trả phí chữ ký và phí ưu tiên tùy chọn vẫn được giữ nguyên.
7. Phí khóa ghi đã thu được sẽ bị đốt cháy 100%.
8. Phí ưu tiên thu được được thưởng 100%.
9. Phí chữ ký thu thập được sẽ đốt 50% và thưởng 50%.

Đề xuất này sẽ làm cho tính năng khóa ghi của Solana (thường) DSIC tương tự như cách EIP-1559 tạo ra TFM (thường) DSIC và MMIC [Rou23] của Ethereum - ngoại trừ trường hợp phí tăng đột ngột.

Chúng ta có thể định nghĩa thuộc tính MMIC như sau:

**Khả năng tương thích khuyến khích người khai thác cận thị (MMIC): Nhà sản xuất khối tối đa hóa tiện ích của mình bằng cách không tạo ra các giao dịch giả mạo và tuân theo các quy tắc đã nêu của TFM. Cận thị có nghĩa là mục tiêu này chỉ liên quan đến khối hiện tại khi đánh giá mức tối đa hóa tiện ích [Rou21].

Bất kỳ cơ chế kéo dài nào đều không hoàn hảo ở chỗ nó có thể không thể hiện chính xác trạng thái nhu cầu hiện tại. Ví dụ: nhu cầu có thể thấp trong một khoảng thời gian dài (và do đó, phí cơ bản động thấp), sau đó tăng đột ngột đối với việc đúc NFT. Điều này có thể xảy ra ở cấp độ toàn cầu (như trong TFM của Ethereum) và thậm chí có thể biến động hơn ở cấp độ mỗi tài khoản cục bộ (như được xem xét trong SIMD-0110).

Tuy nhiên, Solana cũng được hưởng lợi từ thời gian chặn cực kỳ thấp ở đây. Những điều này có thể cho phép phí cơ sở điều chỉnh nhanh hơn trước cú sốc cầu đột ngột, tùy thuộc vào mức độ di chuyển của đường cong. Hình dạng của bộ điều khiển phí ở đây cực kỳ quan trọng.

Thực tế là phí khóa ghi này được tính trên các CU được yêu cầu cũng khuyến khích người dùng và nhà phát triển ước tính chính xác mức sử dụng CU của giao dịch. Điều này tránh được vấn đề mà chúng ta đã thảo luận trước đó khi cơ sở chữ ký phẳng hiện tại không bị phạt khi yêu cầu nhiều CU hơn mức yêu cầu (thậm chí lên đến mức tối đa là 1,4mm CU). Nếu không, ngày hôm nay chỉ có phí ưu tiên mang lại ưu đãi này (vì nó cũng được tính bởi các CU được yêu cầu).

Một lời chỉ trích tiềm tàng ở đây là thị trường phí địa phương dựa trên tài khoản (đặc biệt là đề xuất này, yêu cầu tính toán EMA liên tục cho mọi tài khoản) có thể tốn kém về mặt tính toán. Loại phí đa chiều này không bị ràng buộc, vì bất kỳ tài khoản nào cũng có thể bị tắc nghẽn, điều này có thể gây khó khăn cho một TFM như vậy. Tuy nhiên, trong trường hợp của SIMD-0110, điều này có thể tránh được bằng cách đặt giới hạn trên cho số lượng tài khoản có EMA sử dụng CU có thể được theo dõi tại một thời điểm nhất định.

**Có thể tính toán hiệu quả: Cơ chế đấu giá khối phải được thiết kế sao cho có thể tính toán hiệu quả cho một nhà sản xuất (hoặc người xây dựng) khối nhất định — Thời gian của Eclipse và Solana nhỏ hơn 400 mili giây, điều này đặt ra hạn chế chặt chẽ về thời gian tính toán tối đa cho một thời gian nhất định khối.

Do việc đưa khối Solana vào vẫn không mang tính quyết định ngay cả khi đề xuất này được triển khai, vẫn có thể xảy ra sự cố với việc người dùng cập nhật chính xác giá thầu của họ trong thời gian thực để đảm bảo giao dịch của họ được bao gồm trong khối. Việc giải quyết thêm vấn đề này đòi hỏi phải thay đổi bộ lập lịch khi chúng ta thảo luận trong phần tiếp theo.

Những thay đổi đối với Trình lập lịch mặc định của Solana

Như đã thảo luận trước đó, “bộ lập lịch” là thuật toán mặc định có trong ứng dụng khách xác thực Solana Labs, dùng để lên lịch thực hiện các giao dịch và xây dựng các khối liên tục. Nó đóng một vai trò cực kỳ quan trọng trong thị trường phí của Solana mặc dù hành vi mặc định của nó không được thực thi trong giao thức vì người xác thực có thể chọn chạy các thuật toán khác. Ở đây chúng ta sẽ tập trung vào bộ lập lịch hiện tại và những thay đổi được đề xuất sắp tới do Andrew Fitzgerald thực hiện.

Bộ lập lịch hiện tại của Solana giới thiệu tính năng jitter trong việc xử lý các giao dịch của người dùng bằng cách gán ngẫu nhiên chúng vào một trong bốn luồng giao dịch không bỏ phiếu (hai luồng bổ sung được dành riêng để xử lý các giao dịch bỏ phiếu) trước khi cố gắng sắp xếp các giao dịch còn tồn đọng theo phí ưu tiên và kiểm tra các ổ khóa liên quan ('khóa lấy'), như minh họa trong sơ đồ bên dưới . Nhiều lô giao dịch được kéo để phân bổ cho các luồng trong “Giai đoạn ngân hàng” - quy trình được điều hành bởi trình xác thực Solana trong đó các giao dịch được xử lý và theo đó quy trình lập lịch diễn ra.

Nguồn: Andrew Fitzgerald, Người lập kế hoạch và giai đoạn ngân hàng Solana

Một vấn đề quan trọng với bộ lập lịch mặc định là trong thời gian mạng có hoạt động mạnh mẽ, hàng đợi của mỗi luồng thường chứa đầy các giao dịch xung đột (ví dụ trước khi đúc NFT hoặc sự kiện tạo mã thông báo được mong đợi rộng rãi). Mỗi luồng có thể chứa các giao dịch có khóa đọc hoặc ghi giống nhau hoặc chồng chéo, nghĩa là các giao dịch đó phải được lên lịch lại để thực hiện sau này. Tuy nhiên, kết quả của việc này là trong trường hợp cực kỳ xấu nhất, chỉ một trong bốn luồng lập lịch mặc định có thể thực hiện các giao dịch tại một thời điểm nhất định.

Điểm mấu chốt của việc nâng cấp lên bộ lập lịch mặc định của Solana nằm ở việc chuyển đổi từ phương pháp cũ (được đặt tên là chế độ ThreadLocalMultiIterator) sang phương pháp lập lịch mới, được đặt tên là chế độ CentralScheduler. Bài viết này sẽ chỉ cung cấp một cái nhìn tổng quan và phân tích về những thay đổi. Tuy nhiên, bạn có thể tìm thêm thông tin trong bài viết của Andrew Fitzgerald và <a href="https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7"> bài đăng blog tóm tắt kèm theo của Harsh Patel từ nhóm Tiny Dancer . Dưới đây là tổng quan về quy trình lập kế hoạch mới.

Nguồn: Andrew Fitzgerald, Người lập kế hoạch và giai đoạn ngân hàng Solana

Bộ lập lịch mới bao gồm một bộ lập lịch trung tâm duy nhất nhận các giao dịch từ kênh trước khi kiểm tra các khóa liên quan. Sau thời điểm này, các giao dịch được gán cho các luồng công việc song song cụ thể để thực thi. Bộ lập lịch trung tâm có chế độ xem các khóa đọc và ghi khác nhau được sử dụng bởi một luồng công việc nhất định, cho phép nó xác định luồng tốt nhất cho một giao dịch mới. Khi các giao dịch được thực thi và xử lý bởi một luồng công việc nhất định, một thông báo sẽ được gửi trở lại bộ lập lịch trung tâm để nó có thể đánh giá lại phần nào trong trạng thái của Solana được coi là bị khóa.

Bộ lập lịch sử dụng một thuật toán được gọi là “biểu đồ trước”, là biểu đồ acrylic trực tiếp bắt đầu bằng các giao dịch và đường có mức độ ưu tiên cao nhất (phí) (hoặc chính xác hơn là các cạnh) giữa các giao dịch có mức ưu tiên cao nhất nhất định và các giao dịch sau. các giao dịch có mức độ ưu tiên cao nhất xung đột với nó do các khóa chồng chéo. Điều này (tạm thời) được thực hiện cho cửa sổ “xem trước” có kích thước được định cấu hình trước là 2.048 giao dịch (có thể thay đổi), có thể được thêm vào biểu đồ - các biểu đồ sau đây hiển thị biểu đồ trước hoạt động cho một tập hợp giao dịch nhất định trong đó các cạnh giữa chúng biểu thị các khóa xung đột.

Ngoài việc áp dụng bộ lập lịch biểu đồ trước, phiên bản này còn giới thiệu các hiệu quả bổ sung nhằm giúp giảm chi phí xử lý, chẳng hạn như loại bỏ các yếu tố dư thừa của giai đoạn ngân hàng. Bộ lập lịch mới sẽ cải thiện bằng cách giảm đáng kể xác suất ghi và khóa đọc không thành công trong thời gian hoạt động cao trên Solana. Chúng ta có thể mong đợi sự giảm giật do bộ lập lịch mặc định mới. Tuy nhiên, do tính chất liên tục của quá trình xây dựng khối, sẽ tiếp tục có tính chất không xác định trong việc đưa khối vào.

Phí ghi vào tài khoản có thể hoàn lại (PRAW) của chương trình

Được ủy quyền bởi Godmode Galactus và Max Schneider, SIMD-0016 đề xuất phí Ghi tài khoản có thể giảm giá theo chương trình (PRAW). Họ sẽ trao quyền kiểm soát đáng kể cho các nhà phát triển ứng dụng, vì họ có thể đặt ra các tiêu chí thanh toán và giảm giá các khoản phí này, cho phép họ khuyến khích và không khuyến khích hành vi của người dùng khi họ thấy phù hợp.

Hiện tại, các chương trình Solana không có khả năng xử phạt các giao dịch có được khóa ghi trên trạng thái của chúng. Phí PRAW sẽ cho phép chủ sở hữu tài khoản Solana tính phí các giao dịch không thành công khiến trạng thái của họ bị khóa. Các khoản phí này sẽ được chuyển vào tài khoản có thể ghi mà họ đang khóa. Tuy nhiên, chủ tài khoản có thể đặt các khoản phí này để sau đó chúng sẽ được hoàn lại cho người dùng khi kết thúc giao dịch nếu nó đáp ứng các tiêu chí đã chỉ định.

Đặc biệt, điều này có thể ngăn cản người dùng khóa các tài khoản mà họ không thực sự sử dụng khi thực hiện giao dịch. Điều này hiện có thể thực hiện được vì Solana hiện không có biện pháp kiểm tra nào để xem liệu một tài khoản nhất định có được sử dụng, tiên nghiệm, bởi một giao dịch nhất định đã ghi khóa nó hay không. PRAW cung cấp cho các chương trình một cách để không khuyến khích các giao dịch khóa trạng thái của chương trình nhằm cố gắng xác định một cơ hội với mục đích hoàn nguyên nếu cơ hội đó không còn hiệu lực tại thời điểm thực hiện. Các khoản phí này sẽ được áp dụng ngay cả khi giao dịch không thành công trong quá trình thực hiện.

Ngược lại, người dùng có thể chỉ định số tiền phí PRAW tối đa mà họ sẵn sàng trả trong một giao dịch. Bất kỳ khoản phí nào được chỉ định trong giao dịch cao hơn phí PRAW hiện tại đối với một tài khoản bị khóa ghi cụ thể sẽ được hoàn lại.

Các thành viên của cộng đồng Solana đã chỉ ra các vấn đề với đề xuất này: khả năng các chương trình khác nhau hoạt động hoàn toàn tự chủ dường như chưa tối ưu và khả năng ước tính phí chính xác sẽ khó khăn. Hơn nữa, có những cách đơn giản và thống nhất hơn để giải quyết những vấn đề đau buồn này xung quanh các tài khoản bị khóa ghi, chẳng hạn như SIMD-0110.

**Phản kháng đau buồn: Một tập hợp con của DSIC trong đó người dùng không được khuyến khích trình bày sai danh sách truy cập của họ - trình bày sai các tài nguyên cần thiết cho giao dịch của họ [Gar23].

Đề xuất PRAW có khả năng sẽ không ngăn chặn được thư rác vì nó phụ thuộc đầy đủ vào các nhà phát triển ứng dụng: 1) khả năng phân biệt thư rác với “hành vi bình thường” và 2) tự nguyện chọn tính phí nhiều hơn cho tác động tiêu cực bên ngoài mà họ chịu trách nhiệm một phần trong khi điều đó có thể không xảy ra vì lợi ích tốt nhất của họ khi làm như vậy và họ có thể đơn giản chọn không làm như vậy.

Ngược lại, trong khi các thành viên của cộng đồng nghiên cứu Solana không thể phủ nhận sự chia rẽ trong việc áp dụng phí cơ sở EMA, thì nhìn chung vẫn có sự đồng thuận về việc bổ sung một số thành phần của phí cơ sở tùy theo CU. Điều này có thể khuyến khích các nhà phát triển ước tính CU chính xác và sử dụng CU hiệu quả.

Ý Tưởng Chia Tay

Các mục tiêu về hiệu suất và kỹ thuật độc đáo của Solana đòi hỏi phải cân nhắc TFM riêng. Tất nhiên, việc chuyển thị trường phí hiện tại của Ethereum sang Solana không phải là giải pháp ở đây, nhưng có những bài học quý giá được rút ra từ nó. Điều này rất phù hợp với các cơ chế có cả hai:

1. Trong giao thức - TFM được thực thi đồng thuận (ví dụ: EIP-1559 và SIMD-0110)
2. Ngoài giao thức - PBS thông qua MEV-Boost, cải tiến bộ lập lịch Solana và đấu giá Jito

Đối với cả Solana và Ethereum, các cơ chế trong giao thức và ngoài giao thức dường như cùng tồn tại và phát triển cùng nhau trong tương lai. Sự cân bằng giữa chúng là một trong những câu hỏi cơ bản trong việc thiết kế các hệ thống này. Cuộc tranh luận xung quanh SIMD-0110 thường xoay quanh hai quan điểm đối lập:

1. Các cải tiến về bộ lập lịch và kết nối mạng để giảm hiện tượng jitter sẽ giải quyết đầy đủ các vấn đề được mô tả ở đây, vì vậy những thay đổi lớn đối với TFM trong giao thức là không cần thiết.
2. Mặc dù việc cải tiến mạng và lập lịch ngoài giao thức là cần thiết nhưng chúng vốn không đủ. Cần có áp lực ngược kinh tế trong giao thức.

Định giá tài nguyên đa chiều dưới một số hình thức rõ ràng cũng có giá trị trong cả hai trường hợp. Ethereum đang bắt đầu theo đuổi một TFM như vậy ở cấp tài nguyên cơ bản, với EIP-4844 tách dữ liệu blob ra khỏi thị trường thực thi. Ngược lại, Solana đang đẩy mạnh việc định giá tài nguyên đa chiều ở cấp tài khoản cá nhân để đi tiên phong trong “thị trường phí địa phương”.

Nghiên cứu của TFM ở đây rất tiên tiến và các nhà nghiên cứu không ngừng tìm ra những cách mới và sáng tạo để cải thiện cách thức tính phí trên Solana và các chuỗi khác. Chúng tôi lạc quan rằng tất cả các đề xuất được thảo luận ở đây sẽ tiếp tục giúp Solana hoạt động hiệu quả hơn, có thể mở rộng, thân thiện với người dùng và bền vững về mặt kinh tế hơn nữa.

Khi Eclipse sắp ra mắt mạng chính của chúng tôi, chúng tôi cũng vui mừng chia sẻ thêm về cách chúng tôi sẽ áp dụng công việc hiện có này cho TFM của riêng mình, điều này chắc chắn sẽ tiếp tục phát triển trong nhiều năm tới. Chúng tôi dự định thử nghiệm và thúc đẩy các cơ chế trong lĩnh vực này. Một lợi ích thiết yếu của mô hình mô-đun là nó cho phép việc thụ phấn chéo dễ dàng hơn trong nghiên cứu và kỹ thuật từ các hệ sinh thái khác nhau. Tỷ lệ thử nghiệm này giờ đây sẽ tiếp tục tăng lên, mang lại lợi ích lâu dài cho tất cả mọi người xây dựng ở đây.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Eclipse], Chuyển tiếp Tiêu đề gốc'Cơ chế phí giao dịch Solana & Ethereum: Đề xuất cải thiện TFM của Solana', Mọi bản quyền thuộc về tác giả gốc [Eclipse]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.