從人們需求的角度來看，大多數的需求會集中在頭部，而分佈在尾部的需求是零散的小量的需求，這部分少量的需求會在需求曲線上面形成一條長長的“尾巴”，將這些少量需求累加起來就會形成一個比頭部需求還大的市場。
——長尾效應
1
背景介紹
普通的代幣透過ICO方式發行，並在交易所得到相應的流動性，由於在當前加密數字市場存在較為顯著的長尾現象（前10%的代幣佔整個代幣幣值的95%，佔所有交易量的99%），令許多新幣或者市值較小的代幣無法獲得足夠的流動性。
Bancor的設計從理論上給這部分缺乏流動性的代幣提供一個可以進行買賣交易的地方，即用智慧合約充當做市商這樣的一個角色，使用者可以直接跟智慧合約進行買賣，透過一定的演算法實時報價，模擬了一個代幣買賣環境，裡邊的幣價隨著使用者不斷買入而增高，隨著使用者不斷的賣出而下跌。
與傳統交易所相比，Bancor的設計有幾點不一樣的地方（只考慮在智慧合約進行買賣，不考慮存在外部交易市場的情況）。
2
與普通交易的區別
第一
透過數學公式模擬的市場環境是一個絕對理想主義的定價體系，即價格與供應量遵循某一人為定義的函式關係，而現實世界由於供應量無法隨時調整，價格與供應量無法形成一一對應的關係，兩者的定價機制存在很大的不同。
普通的ICO供應量是人為先確定的，再透過市場需求（使用需求和投機需求）的變化帶動價格的漲跌，價格預測存在一定不確定性。Bancor協議的原理是透過市場需求確定供應量和對應的價格，當代幣價格在市場可承受範圍之內，市場需求不斷上升時，代幣會不斷被釋放出來，同時由於價格的上升，會使得市場需求降溫，早期買入者選擇賣出獲得收益，人們可以根據系統上代幣的出售數量準確預測價格漲跌幅度，使得市場更具可操控性。
第二
滑點交易，完美的根據數學公式進行報價的系統使得代幣沒有價格承載量，即同一筆交易，交易量的大小會導致最後成交的價格不同。
由於跟智慧合約的交易不是傳統的撮合買賣方的交易，可以將其當成普通的交易分開為獨立、不在同一時點、價格不同的兩個智慧合約交易，稱為非同步流動性。
傳統的交易其實是一個雙想要的問題，即買方和賣方對同一事物在同一時點達成一致的價格協商，當交易深度不足時，訂單成交的可能性將會降低（傳統交易所會透過將風險轉嫁給做市商的方式來提高成交率，然而做市商也會出於平衡風險頭寸的考慮，無法百分百保證當前市價的訂單成交），而非同步流動性降低了達成交易所需的門檻。與此同時，使用者需要為滑點買單，因為即使是微小的一筆買入量（賣出量）也會使得價格上升（下降），量越大價格變動越大，而一個流動性越強的市場，交易對價格的衝擊相對越小，買賣雙方的合作可以抵消掉這部分的價格衝擊。即使當很多人使用智慧合約進行買賣，使得價格波動總是在一定範圍內，但由於類似於單機的交易，個人總是要承擔自己買賣的數量帶來的市場價格的波動。
除此之外，由於曲線的人為設定，並不一定能反應市場價格和數量方面的需求關係，存在失真。從這個方面說，bancor協議並不適合於形成一個成熟的交易市場，但它對早期流動性缺失和專案交易啟動能提供一定的幫助。
第三
代幣的發行和回收（即使是先前募資發行的那一批代幣，也可以賣回智慧合約）根據市場需求進行，能較好的反應市場需求，不會稀釋到單價，減少超發、濫發的情況發生。
由於合約裡邊儲備的價值總是有限的且小於代幣的價值，當市場不再有買入量時，先兌換的人總是能兌到較高的價格，因此當市場對代幣不看好時，人們會傾向於先變現，因此容易發生擠兌。
第四
傳統做市商透過雙邊報價的價差獲取收益，bancor協議買賣曲線是同一條，不存在價差問題，即買入價與賣出價相等，減少了中間費用。
3
bancor演算法的數學原理
在bancor的設計中，存在兩個池，一個是connector，一個是smart token，可以理解為一個是儲備金池，一個是代幣池，儲備金池裡的資金可用於使用者向智慧合約賣出代幣時兌換出儲備金。
根據bancor白皮書，
在bancor的另一份資料中，對函式進行了較為詳細的推導。假設smart token的總價值為SP（S為供給量，P為價格），儲備金率為F，儲備金總價值為R，即R=FSP，對於任一無窮小的購買量dS，需要支付PdS的儲備金，即dR=PdS，同時對R=FSP進行微分，得到
令α=1/F-1，
由此得出代幣的實時價格公式。可以看出，當CW取不同值時有不同的函式曲線，其中CW取值越小，價格波動越劇烈。
使用者向智慧合約購買T個代幣，即將原有供應量推高到+T，需要付出的代價為E，利用積分公式，
從價格公式不難看到，隨著供應量的增加，價格在不斷上漲，決定曲線的關鍵是儲備率CW，透過更改CW可人為定義曲線的形態。從幣價上漲邏輯來說，由需求推動供給增加，可以抑制過度發行造成價格下降，有效調節市場需求和供給的關係。但是從滿足市場需求來說，這種變動模式會被投機者利用，在早期買入大量代幣，過度哄抬價格，使得真正有需求者需要付出很高的成本，當成本收益比變大時導致市場需求被抑制，不利於生態的擴大和發展。
除了單個儲備池的普通模式，bancor協議還提出了兩個儲備池的模式，其中，令牌的兩個儲備池權重之和為100%的模式稱為中繼令牌，該模式可用於為兩種已存在的令牌提供兌換通道。例如，A、B是分別和X相互連線的兩個令牌，使用者可以透過將A換成X，將X換為B實現A和B的互換。
4
EOS RAM的數學解析
Bancor協議出來後為專案提供了一種新的定價思路和交易模式，為缺乏流動性的代幣賦予一定的投資價值，當然也可以將某一無法流通的資源代幣化，再加入bancor演算法，透過市場流動性促進資源的有效利用，eos在這方面做出了嘗試。
我們知道，在EOS網路中，目前提供使用的資源有兩類，一類是RAM，購買型的；另一類是CPU和網路頻寬，抵押型的。把EOS理解為區塊鏈作業系統，CPU和網路頻寬是跟時間相關的，一定時間內你可使用的CPU和網路頻寬是有限的，可使用量和你抵押的EOS數量相關，隨著時間的流逝，CPU和網路頻寬會慢慢恢復，抵押的EOS在不用時可以全部退回。
而RAM其實就是我們常說的記憶體。由於EOS是0.5s一個區塊的高速運轉，系統中的賬號資訊、智慧合約執行資訊的當前狀態是儲存在記憶體中的，因此這些資訊需要長期佔用記憶體。當儲存賬號狀態的空間不足即RAM不足時，某些交易及其他操作就無法執行。例如你雖然餘額中有足夠的EOS，但RAM不足，你仍需要先購買RAM才能部署智慧合約。
RAM的交易機制採用Bancor演算法，透過中間令牌RAMCORE來保證EOS和RAM之間的交易流通性。從EOSIO程式碼看EOS->RAM的交易，是透過EOS->RAMCORE， RAMCORE->RAM來實現的，反之一樣。以下為RAM公式推導過程
EOS->RAMCORE：
RAMCORE->RAM：
一般情況下RAMCORE都是遠遠小於A的，即A-RAMCORE=A
將第二個式子代入第一個式子整理得到RAM和EOS的關係式
所以，當有使用者買入RAM時，B和C的變化情況為
那麼，
由此我們可以知道，無論RAM市場如何波動，B和C的乘積幾乎時保持不變的，即BC=64*1024*1024 KB*100萬EOS，即67108864000000，設為G，那麼
最終，計算單個EOS能兌換RAM的數量，
則，RAM的價格函式為
用excel表格擬合出RAM的價格變化圖
由於後邊數值差距過大，將已出售的數量最高設定為50G，具體價格走勢如圖所示
ram的歷史價格走勢如下圖所示
從6月19日開始ram的價格完美按照設定的函式逐步升高，並在14日後到達某一價格點快速回落，後邊價格一路走低，截至發文，ram的價格為0.065EOS/KB。可以看到，ram所設定的函式曲線，當已出售的量到達某一點時價格處於極大風險值中，此時系統再出售或回收數量極小的ram，都會引起價格瘋狂的上漲或下跌，不利於價格在高位保持。同時這種特性在場外市場還沒建立的情況下，無法保持ram更好的流通，同時更容易被投機者操控價格。
目前ram已經透過了擴容方案，eos社羣希望用增加供應的方式降低價格，截至發文達RAM的總數為89.4G。我們將ram的供應量分別設定為69G和74G，並畫出相應的函式影象。
我們同樣將已出售的量定為50G以下，得到如下函式曲線。
從函式影象上的反應可以看到這種解決方式只能暫時延緩ram價格再次飆升的時間，且隨著擴容，ram到達極限值的價格波動會更大，風險更高。
由於ram始終是屬於稀缺資源，當開發者們持續在eos上進行開發，將來仍不可避免會面臨系統資源使用成本極大的問題(由於投資炒作使得真正的開發需求得不到滿足，儘管目前的RAM使用率並不高)。除非改變中間令牌RAMCORE的儲備率，進而使得價格曲線發生改變。然而從bancor曲線的定義來看，越平緩的價格波動需要越高的儲備率，這意味著專案方需要越多的資金鎖定在合約裡供使用者兌換，顯然這對專案方來說是不利的。從這個層面來說，ram採用bancor的中繼演算法無法使得eos的生態可持續、穩定的發展，可能只會成為投資的溫床。
5
總結
Bnacor演算法為通證的流通和升值創造了一個新的邏輯，從理論上說可以為缺乏流動性的通證帶來一定的流動性或者作為新通證的啟動方式，然而這種方式是存在缺陷的，除了文章開篇提到的一些缺陷之外，儲備池的模式還存在其他的漏洞，例如，儲備貨幣價格波動。當儲備貨幣大幅貶值，有可能使得供應量越大價格越高的設定並不成立。這些特點使得這樣的市場不足以成為一個較為成熟和完善的市場，這一點其實bancor的建立者也注意到了，因此在其白皮書上反覆提到了bancor演算法定價市場作為一個套利市場的存在。
如果一個通證的流通市場想要走向成熟的話，仍不可避免要有普通交易市場的融入，使得真正的市場需求和價格達到平衡，從而系統可以穩健的發展。同時，在設計bancor曲線時也有諸多考慮的因素，需要結合通證屬性和專案方的需求進行設計。
參考文獻
[1] EOS智慧合約開發（十二）EOSIO購買RAM中Bancor協議演算法分析
https://blog.csdn.net/jambeau/article/details/81366689?utm_source=blogxgwz9
[2] bancor_protocol_whitepaper_en
[3] Bancor Conversion Function
