Paradigm新文:MEV稅與優先排序

24-06-05 13:33
閱讀本文需 34 分鐘
总结 AI 總結
看總結 收起
原文標題:《Priority Is All You Need》
原文作者:Dan Robinson, Dave White
編譯:Joyce,BlockBeats

編者按:
6 月5 日,Paradigm 的研究總監Dan Robinson 和研究合夥人Dave White 發表研究文章,提議徵收礦工可開採價值(MEV) 稅。這種稅收允許任何應用程式捕獲其 MEV,同時保持可組合性。該機制現在可以在 OP Mainnet、Base 和 Blast 以及其他 OP Stack L2 平台上使用。文章提出,智能合約可以根據交易的優先費來收取一定比例的費用,從而捕獲交易中的 MEV。
文章也指出了MEV 稅的局限性,包括它依賴於區塊提議者嚴格遵守競爭優先排序規則,以及在以太坊L1 上可能無法有效運作的問題。此外,文章還討論瞭如何透過設計來緩解 MEV 稅的一些缺點,例如激勵不相容、完整區塊問題、已恢復的交易、洩露用戶意圖等。 BlockBeats 將文章編譯如下:


介紹


在這篇文章中,我們將介紹MEV 稅,這是任意應用程式可以用來捕獲自己的MEV 的機制。這種機制現在可以在 OP Mainnet、Base 和 Blast 等 OP Stack L2 上使用,因為這些鏈上的區塊提議者遵循一組我們稱為競爭優先排序的規則。


為了對其中一條鏈徵收 MEV 稅,智能合約會收取一筆費用,該費用是交易優先費的函數。如果應用程式對搜尋者每 1 美元的優先費收取 99 美元的 MEV 稅,那麼它可以捕獲該交易的 99% 的競爭性 MEV。


MEV 稅是一種簡單的技術,可以開啟廣闊的設計空間。您可以將它們視為允許鏈上的任何應用程式運行自己的自訂 MEV 拍賣,而無需任何自己的鏈下基礎設施,只需連接到由區塊提議者運行的單一共享拍賣即可。


我們闡述如何利用MEV 稅來解決MEV 研究中的三個主要問題:


去中心化交易所(DEX) 路由器可最佳化交換者收到的價格;


自動做市商(AMM),最大限度地減少流動性提供者經歷的損失與再平衡(LVR);


讓用戶捕獲其交易創建的任何「後台運行」MEV 的錢包;


但有一個問題。 MEV 稅只有在區塊提議者嚴格遵守競爭性優先排序規則的情況下才有效,其中包括按優先費對交易進行排序,而不進行審查、窺視或延遲任何交易。如果區塊提議者偏離這些規則,他們就可以逃避 MEV 稅,為自己獲取價值。因此,如今,MEV 稅依賴於信任的L2 排序器,並且可能根本無法在以太坊L1 上發揮作用,在以太坊L1 中,區塊構建由競爭性的構建者拍賣主導,從而最大限度地提高提議者的收入。


儘管如此,MEV 稅收的力量和靈活性表明,對於目前能夠提供這種服務的平台來說,優先排序可能是正確的選擇。競爭優先排序的相對簡單性表明,可能存在一種可行的方法來以分散的方式強制執行,而不必信任單一排序器。我們希望這篇文章能夠激發對此問題的進一步研究。


優先排序


當有人在以太坊L1 或L2 上發送交易時,他們會指定優先費,並將其支付給區塊提議者。您可以想像這被指定為 priorityFeePerGas(優先排序費),一個數字乘以交易中使用的 Gas 以獲得 builderPriorityFee—以 ETH 表示的總付款。


以太坊協定中沒有規定區塊中的交易必須依降序貪婪排序 priorityFeePerGas。然而,這是一種流行的構建區塊的方式——例如,它是 OP Stack 鏈的排序器以及 geth 和 reth 使用的預設演算法。優先排序不僅可以讓交易者有效地表達其交易的緊迫性,還可以自然地將某些類型的 MEV 傳遞給區塊提議者。


發生這種情況是因為優先排序將 MEV 的競爭變成了優先 gas 拍賣。當有機會從與鏈的交互中獲利時,例如透過 AMM 與中心化交易所進行套利,搜尋者會競相搶佔先機。如果鏈使用優先排序來確定交易包含和排序,則搜尋者會為其交易設定高優先費用來競爭。


在無風險利潤競爭為零的競爭場景中,獲勝的搜尋者最終應該支付全額 MEV 優先費。因此,如果透過與合約互動可以獲得 100 ETH 的利潤,則第一筆索取該利潤的交易將設定 100 ETH 的優先費用。 (我們在局限性部分討論了一些注意事項)。


MEV 稅


假設智能合約想要從與之互動的任何交易中捕獲MEV。有大量關於智能合約可以嘗試捕捉自己的 MEV 的不同特定應用方式的研究。


但事實上,我們不一定要了解任何有關應用程式的資訊。如果我們知道該區塊是透過競爭性優先排序來建構的,那麼我們就有一個關於交易中 MEV 數量的通用訊號:優先費。


我們建議智能合約可以查看交易的優先費用,並收取自己的費用作為其某些遞增函數。例如,合約可能要求呼叫者將 ETH 中的 applicationPriorityFee = 99 * proposerPriorityFee 轉移到合約中。


這項新費用由發送交易的搜尋者支付,因此它會影響該搜尋者的行為。如果機會中有 100 MEV,則獲勝交易現在將僅設置 1 ETH 的優先費用,因為這將導致總共支付 100 ETH(1 ETH 支付給區塊提議者,99 ETH 支付給智能合約)。任何更高的優先費都會使交易變得無利可圖;任何較低的優先費用都會導致失去機會給設定較高費用的競爭對手。這意味著智能合約已經捕獲了交易中 99% 的 MEV。



我們將智能合約徵收的這筆額外費用稱為MEV 稅。 MEV 稅允許應用程式為了自身利益而劫持優先排序,從而允許其為其用戶重新捕獲 MEV,而不是將其洩露給區塊提議者。


如果該費用作為 priorityFeePerGas 的函數增長得足夠快,那麼提議者將只獲得微不足道的 MEV。由於 priorityFeePerGas 以 wei(1 ETH 的十億分之一)計價,因此我們需要處理很多精度。例如,只要 MEV 稅足夠敏感,50,000 的 priorityFeePerGas 將導致過高的稅,那麼支付給提議者的總金額將低於 0.01 美元。 (5)


然而,有一個重要的警告。正如“局限性”部分中所討論的,MEV 稅只有在區塊提議者遵循某些規則(我們稱之為“競爭性優先順序”)時才起作用,而不是為了最大化自己的收入而偏離這些規則。以不信任的方式執行這些規則是一個懸而未決的問題。


單應用MEV 捕獲


在這裡,我們概述瞭如何在保證使用競爭優先順序進行區塊建構的鏈上,MEV 稅可用於緩解MEV 中的三個重要問題:讓DEX 介面改善交換者的交易執行,讓AMM 減少套利損失他們的LP,並讓錢包通過出售用戶的反向運行權利來減少用戶的MEV 洩漏。


去中心化交易所路由器


在UniswapX 和1inch Fusion 等基於意圖的DEX 路由協定中,使用者(Alice )簽署交換意圖,搜尋者競相以最優惠的價格為Alice 路由或填充該意圖。


UniswapX 目前版本使用兩種機制來進行競爭:荷蘭式拍賣,Alice 的限價會隨著時間的推移而變化,直到搜尋者填滿為止;以及初始鏈下詢價(RFQ) 拍賣,用於設定荷蘭式拍賣的起始價格。


在確保競爭性優先排序的平台上,UniswapX 可以用單一機制取代這些機制:MEV 稅。它可以透過讓用戶簽署任何人都可以立即填寫的訂單來實現這一點,但執行價格設定為交易優先順序的函數。


例如,如果 Alice 有一個出售 1 ETH 的 UniswapX 訂單,她可以將訂單的執行價格定義為 minimumPrice + ($0.01 * priorityFeePerGas)。 minimumPrice 可能是某個固定值,她預計該值將明顯低於當前價格。


搜尋者將透過提交交易來競爭填補 Alice 的訂單。無論哪筆交易具有最高優先級費用且不恢復,都將完成訂單,這應該保證交換者獲得搜尋者可以找到的最佳價格。 (「限制」部分討論了一些例外情況。)


如果Alice 的最低價格為3,000 美元,而ETH 的當前價格為3,500 美元,則獲勝交易中的priorityFeePerGas 約為50,000 。 (請注意,在一筆花費 200,000 Gas 的交易中,這將導致僅向區塊提議者支付約 100 億 wei(約 0.000035 美元)。)


與 UniswapX 中使用的現有機制相比,這具有一些潛在的好處。


與使用荷蘭式拍賣的訂單相比,使用 MEV 稅的訂單可以更快完成且價格更優惠。正如本文所討論的,由於區塊之間的價格變動,鏈上荷蘭式拍賣會向 MEV 洩露一些價值,並且可能需要許多區塊才能完成。相較之下,使用 MEV 稅的訂單通常可以在下一個區塊中完成,同時捕獲絕大多數 MEV。


與鏈下詢價不同,使用 MEV 稅的訂單的拍賣會在鏈上交易執行時自動進行。這意味著,可以保證得標者只有在鏈上交易成功的情況下才承諾填寫訂單。這可以使 AMM 等鏈上流動性更容易與鏈下流動性競爭,這意味著 UniswapX 可以作為 Uniswap v4 等多池系統的更有效的路由器。


AMM


通常情況下,AMM 會將價值洩露給套利者,他們根據區塊頂部的過時價格進行交易,正如損失與再平衡論文中所討論的那樣。我們可以使用 MEV 稅來讓 AMM 捕獲 MEV。為了簡單起見,我們將討論如何在沒有集中流動性的情況下在 AMM 上發揮作用。 (如果您對如何透過集中流動性來解決此類問題感興趣,Sorella 將很快發布一種解決方案。)


AMM 可以透過收取額外費用作為交易優先費的函數來捕獲MEV,從而允許其拍賣在區塊中首先進行交易的權利。有多種方法可以計算和計價該費用。我們將討論一個可以說是中性的-以資金池流動性為單位,sqrt(xy)。獲勝的交易將是最大程度增加礦池流動性的交易。


當在區塊中的池上執行第一個交易時,池可以強制執行條件(將a 作為某個常數),而不是強制執行條件x_end * y_end > x_start * y_start :

x_end * y_end > (sqrt(x_start * y_start) + a* priorityFeePerGas)^2


該公式將激勵套利交易者以真實價格進行交易,並且在該交易之後,池中的中點價格應該是真實價格。


在第一筆交易之後,交易可以像 Uniswap v2 上一樣進行,並具有固定的掉期費用。想要在池中進行交易而不支付額外 MEV 稅的不知情交易將設定較低的優先費用。


還有許多其他方法可以對 AMM 實施 MEV 稅,這些方法會產生不同的效果。例如,MEV 稅可以以互換的輸入或輸出代幣計價,可能會影響池所應用的互換費用百分比,或者可以確定用戶交易的最低價格。我們認為這是一個值得探索的有趣的設計空間。


逆行拍賣


上述描述顯示如何設計某些應用來避免 MEV 洩漏。然而,如果錢包想要嘗試幫助用戶捕獲他們從與任何應用程式互動的任意交易中創建的 MEV,甚至是那些不包含 MEV 稅的應用程序,該怎麼辦?


例如,當 Alice 在 AMM 上進行大額交易時,她有時會為「backrunners」創造套利機會,將價格拉回。這通常會洩漏給 MEV,而不是洩漏給 Alice。


MEV-Share 和 MEVBlocker 是兩個允許用戶從交易中捕獲 MEV 的協議,但它們依賴複雜的鏈下拍賣系統。訂單流拍賣設計空間描述了一些其他解決方案。


MEV 稅與基於意圖的智能合約錢包相結合,可以讓我們建立一個替代系統來為 Alice 捕獲後台運行的 MEV。假設 Alice 沒有創建在 AMM 上進行交易的交易,而是簽署了任何人都可以提交到 Alice 的智能合約錢包以使其採取該操作的意圖。 Alice 的智慧合約錢包向提交該交易的任何人收取 MEV 稅,該稅支付給 Alice。


提交 Alice 意圖的搜尋者將擁有反運行她的專有權利,因為他們可以在同一筆交易中自動執行此操作。因此,如果搜尋具有競爭力,那麼 Alice 的所有利潤都應該透過 MEV 稅歸入 Alice 手中。


請注意,該系統不一定能保護用戶免受涉及搶先交易用戶交易的攻擊,因為搶先交易用戶的交易可能能夠避免向該用戶支付 MEV 稅。這個問題(以及一些可能的緩解措施)將在下面的限制部分中更詳細地討論。儘管如此,這至少可以是使用公共記憶體池且沒有任何緩解措施的系統的改進。


其他用例


除了這些例子之外,MEV 稅的其他潛在用途可能包括目前使用鏈下或荷蘭式拍賣的幾乎所有事物,例如:


預言機捕獲其創造的預言機可提取價值的協議,例如Oval;

Blend 等NFT 抵押貸款協議的再融資拍賣;

借貸協議清算的洩漏價值低於荷蘭式拍賣;


跨應用MEV 捕獲


上述解決方案旨在捕獲MEV 與單一應用程式的交互作用。但有時搜尋者可能可以透過在同一事務中與多個應用程式互動來獲取更多價值。


如果這些應用程式中只有一個具有MEV 稅,則交易中的所有MEV 都應轉至具有MEV 稅的應用程序,無論MEV 稅多高或多低。


但是,如果搜尋者的交易與使用 MEV 稅的兩個應用程式互動怎麼辦?例如,如果有一些 MEV 只能透過針對繳納 MEV 稅的 AMM 填寫上述其中一份繳納 MEV 稅的 UniswapX 訂單來捕獲,該怎麼辦?


在這種情況下,每個應用程式捕獲的超額 MEV 的相對金額取決於這些應用程式如何設定其 MEV 稅。如果MEV 稅收取的價值app_i 由函數tax_i(priority) 給出,則獲勝交易的優先順序可以透過求解以下等式中的優先順序來確定:

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV


(從技術上講,我們可以為priorityPerGas * gasUsed 添加第三項,以說明支付給區塊提議者的優先權費用,但我們將忽略這一點,在正常情況下它可能可以忽略不計)


在MEV 稅與priorityPerGas 呈線性關係的簡單情況下(因此tax_1(priorityPerGas) = a_1 * priorityPerGas),您可以求解每個應用程式收到的MEV 份額:


a_1 * priorityPerGas + a_2 * priorityPerGas = MEV
priorityPerGas = MEV/( a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV


在設定自己的MEV 稅時,應用程式面臨著權衡- 更高的稅收讓它在跨應用程式MEV 發生時獲得更大份額,但這意味著如果存在競爭方式來提取它,它可能會錯過一些跨應用程式MEV。例如,如果有一個 AMM 對每筆交易收取 MEV 稅,那麼 MEV 稅 UniswapX 訂單可能更有可能由不同的 AMM 或鏈下填充者填充。


在許多情況下,可能存在一種均衡,其中兩個應用程式設計其 MEV 稅,以便以最大化各自利潤的方式共享 MEV。例如,MEV 稅 AMM 可能希望從區塊頂部附近的單一知情交易者那裡獲取價值,但隨後希望以較低的固定利率向其他交易者和應用程式(包括使用 MEV 稅的應用程式)提供流動性。費用。在這種情況下,AMM 可能會設定相對較低的MEV 稅(例如$0.00001 * priorityFeePerGas),以便套利交易(如果有)發生在區塊的早期,然後對後續交易不收取MEV 稅區塊中的交易。像 UniswapX 這樣想要與 AMM 互動的應用程式可以設定更高的 MEV 稅(例如 $0.01 * priorityFeePerGas),以確保在池已經套利後將其交易包含在內。考慮到這些相對稅收,即使 UniswapX 訂單中只有 1 美元的 MEV 和 50,000 美元的 MEV,AMM 最終也會先被套利。


我們認為這是一個值得未來研究的廣闊設計空間。


限制


MEV 稅有一些複雜性和缺點,我們認為這些都是未來研究的有趣領域。


激勵不相容


MEV 稅對於壟斷區塊提議者來說不具有激勵相容性。它們只有在交易包容性存在公平競爭的情況下才能發揮作用,而只有當區塊提議者遵循我們稱之為“競爭性優先排序”的規則,而不是最大化自己的收入時,這種情況才會發生。非正式地列舉一些建議規則,包括但不限於以下幾點:


優先排序。區塊內的交易必須依 priorityFeePerGas 降序排列。


抵制審查制度。如果區塊提議者在區塊期間收到事務 t1,且該區塊未滿或包含某些事務 t2,例如 t2.priorityFeePerGas < t1.priorityFeePerGas,則該區塊必須包含事務 t1。


交易前隱私。區塊提議者必須透過私有端點接受交易,並且在提交到區塊之前不得與其他任何人共享此類交易,或使用這些交易的內容作為建立自己的交易的輸入。


沒有最後的審查。區塊提議者必須設定一個明確的區塊時間,在此時間之前,他們接受任何人的交易請求;在此時間之後,他們不再接受任何人的交易請求。


如果違反這些屬性中的一項或多項,可能會削弱 MEV 稅的有效性。違反審查制度的區塊提議者可以透過排除競爭交易並提交為自己佔便宜的零優先交易來避免大多數 MEV 稅。違反交易前隱私的區塊提議者可以從其他交易中竊取MEV 或查看他們的優先費用,以確切地知道自己需要設置多高的費用,而能夠比其他人晚提交交易的區塊提議者將獲得免費的「最後看看是否要以高於其他人的價格獲得機會,這兩種情況都可能造成逆向選擇問題,最終阻礙競爭。


不幸的是,雖然第一個屬性很容易在協定層強制執行,但以不信任的方式強制執行其他屬性是一個懸而未決的問題。情況下,需要信任承諾這些規則的單一定序器不會偏離這些規則,如果提議者將區塊構建外包給競爭性收入最大化拍賣(例如以太坊L1 的MEV-Boost),區塊可能不會跟隨它們。它們也可以透過使用共識、密碼學和/或可信賴執行環境的某種組合的去中心化機制來解決,例如 Sorella 的 Angstrom、Flashbots 的 SUAVE、無領導拍賣或多重性。


完整區塊


當區塊完全滿時,MEV 稅正常運作的例外就會發生。在這種情況下,區塊提議者可能不得不放棄優先順序較低的交易,而不是簡單地將它們納入區塊。由於與 MEV 稅應用程式互動的交易可能具有極低的優先費用,因此這些應用程式可能會被不使用 MEV 稅或 MEV 稅極低的應用程式擠出。然而,在使用類似 EIP-1559 的機制來設定單獨的基本費用的鏈中,區塊完全填滿的情況應該相對罕見。此外,考慮到當區塊已滿時某些交易需要延遲,透過設定更高的 MEV 稅來延遲表示較低緊迫性的交易可能是一個合理的結果。


已恢復的交易


MEV 稅實際上依賴單塊拍賣,其中每個「出價」都是一筆交易。這些拍賣的一個缺點是,失敗的出價通常會導致恢復的交易被包含在鏈上,支付一些基本費用並導致鏈擁堵。


如果排序器可以完全排除失敗的事務,這將緩解這個問題,儘管即使使用集中式排序器也很難實現。 (它也不會嚴格遵守上述抗審查屬性,儘管可以調整該定義。)更複雜的定序器可以透過允許交易指定它們正在參與哪些有爭議的拍賣來優化此過程,從而使定序器能夠足夠的資訊來跳過它知道會失敗的後續事務。


洩漏使用者意圖


MEV 稅只有在搜尋者之間存在競爭的情況下才有效,這意味著這個機會需要在某種程度上廣為人知。對於像 AMM 這樣的應用程序,機會在鏈上可見,這應該會自然發生。但對於基於意圖的路由或後台拍賣等應用程序,這意味著應用程式可能需要與搜尋者共享用戶的意圖。


在某些情況下,在用戶意圖實現之前傳播用戶意圖而造成的臨時隱私損失可能會以 MEV 稅無法收回的方式洩漏價值。


例如,假設 Alice 想要使用上述的後台拍賣協議購買低流動性代幣。她發布了智能合約錢包的簽名意圖,以在 AMM 上購買該代幣,並設置一定的滑點容差。搜尋者可以在高優先級交易中競相將該代幣的價格推高至她的滑點容忍度,而無需填寫用戶的訂單。然後,獲勝者Bob 可以通過在低優先級交易中包含並反向運行它,以非競爭性的方式滿足Alice 的意圖,從而夾住Alice 的交易並給她一個更差的價格,同時逃避她的MEV 稅。購買 NFT 也可能會出現類似的問題。


要注意的是,這樣的攻擊對 Bob 來說是有風險的,因為他無法保證在購買代幣和賣給 Alice 之間的原子性。一個天真的Bob 可能會陷入「夾擊撕裂」陷阱:Alice 先發布意圖從自己手中購買一個無價值的代幣,Bob 為了夾擊她的交易而購買了該代幣,但在Bob 完成夾擊之前, Alice 撤回了她的意圖。


應用程式還可以透過限制與其共享意圖的搜尋者集合並監控他們的行為來緩解這種情況,就像許多現有的訂單流拍賣所做的那樣。


也可以將 MEV 稅與具有隱私意識的建構器功能結合起來,就像 Flashbots 為 SUAVE 設計所設想的那樣。


最後,如果 Alice 認為分享意圖的成本超過了競爭性搜尋的收益,她可以自己建立交易並將其直接提交到區塊中。如上所述,競爭優先排序的理想實現將為區塊提議者提供交易前隱私。


相關討論


優先 gas 拍賣。 Flash Boys 2.0 論文研究了去中心化區塊鏈中優先排序的一些動態,該論文創造了「礦工可提取價值」這個術語。該論文指出,以太坊礦工(當該網絡使用工作量證明時)已經按優先級排序交易,並且套利者依靠這種行為參與“優先gas 拍賣”,他們在其中競標被納入的權利第一個區塊,這導致去中心化交易所套利的大部分MEV 歸礦工所有。


先到先得。透過交易排序規則來緩解MEV 的一些嘗試,例如Themis 或Arbitrum One 的當前排序器(7) 專注於執行不同的排序規則,先到先服務(有時稱為“公平排序”),其中區塊提議者必須按照他們看到交易的順序對交易進行排序。


優先排序採用不同的方法-平等對待在給定時間內到達的交易,並按其聲明的優先順序對它們進行排序。


先來先服務很難在具有多個驗證器的真實網路環境中執行甚至定義。即使使用單一可信任排序器,它也可能導致浪費的延遲競爭和垃圾郵件。最後,MEV 稅可能能夠消除先到先得排序無法消除的某些類型的 MEV,例如資產價格不連續「跳躍」帶來的套利利潤。優先排序相對於先到先服務排序的潛在優勢在某種程度上與 Budish、Cramton、Shim (2015) 中討論的離散時間相對於連續時間交換的優勢有關。


與此同時,雖然預設優先級排序似乎會向 MEV 洩露價值,但這篇文章展示瞭如何設計應用程式來重新獲得它。


費用共享。 Blast 是以太坊 L2,與交易中存取的智慧合約共享部分優先費和基本費用。


MEV 稅允許類似的事情(至少對於優先費用),但可以在任何使用競爭性優先排序的鏈上的應用程式層實施,而不需要對費用共享的特殊支持。它們還允許應用程式將自己的稅費定義為優先費的自訂函數,從而提供更大的靈活性,並可能提高 MEV 感知應用程式的可組合性。


無需信任的解決方案。本文重點討論平台使用競爭性優先排序的動機以及利用平台的方法,而不是討論如何以不信任的方式強制執行它。


先前已經對競爭優先級排序所需的每個其他屬性進行了重要的討論。例如,在 Fox, Pai, Resnick (2023) 中,作者討論了在缺乏審查阻力的情況下鏈上拍賣的漏洞,並描述了使用多個並發提議者的抗審查拍賣的設計。然而,他們並沒有建議交易的具體順序。


還有其他關於建構信任最小化區塊建構機制的研究,包括Flashbots 的SUAVE、Sorella 的Angstrom、Leaderless Auctions、Espresso 和Offchain Labs 的去中心化Timeboost,以及Péter Szilági的強制公共交易納入。


我們希望這篇文章鼓勵 L2 考慮使用優先排序(OP 堆疊預設支援),並鼓勵應用程式在支援的情況下嘗試 MEV 稅。我們也希望它能激發對 L1 和 L2 上信任最小化競爭優先排序協議的進一步研究。


原文連結


欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方账号:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
本平台現已全面集成Farcaster協議, 如果您已有Farcaster帳戶, 可以登錄 後發表評論
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交