📜 [專欄新文章] Ethereum Plasma Debit and More Viable Plasma
✍️ Kimi Wu
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
看完上篇Plasma MVP跟Plasma Cash的介紹，感覺Plasma MVP目前還處於是概念上的階段，正式上線好像還有段距離。Plasma Cash每個coin都是不可分割的，在實際上的使用上有點困難。而本篇是要接續介紹Ethereum researcher 們更新的提案-Plasma Debit跟More Viable Plasma。
Plasma Debit
Plasma Debit要解決的就是Plasma Cash 每筆進帳不可分割的問題。Plasma Cash的帳戶裡只有一個值（而且值等於1），在Plasma Debit改成兩個值a跟v。v 代表這個帳戶最多可以擁有多少錢（也就是存了多少ETH進Plasma chain）a 是目前帳戶裡的錢 舉例來說，
1. 甲存了5 ETH進入Plasma chain後，v=5, a=52. 甲轉2 Plasma token給乙，v=5, a=3可以想作是信用卡的最高額度(v)跟還可以使用的額度(a)。
但是，這裡有個問題，在最一開始大家的a跟v的值都一樣，代表著大家不能相互轉帳。什麼意思呢? 舉例來解釋一下
1. 甲,乙各存了5ETH, 7ETH進Plasma chain，此時甲：(v=5, a=5), 乙：(v=7, a=7) 2. 甲想轉帳給乙，但因為乙的 v=a，若甲轉給乙則會造成乙的 a>v 的狀況，這在設計上是不允許的（信用卡公司給你5萬的額度，總不能刷超過5萬吧） 為了要有流動性，operator可以透過不同的function存錢進你的帳戶（也就是某個coin），也就意味著你的v值會變被增加（當然會需要付一些手續費給operator），以上例來說3. operator提供 2ETH的額度給乙（v=9, a=7） 4. 甲就可以轉 2ETH給乙（甲：(v=5, a=3), 乙：(v=9, a=9)）
目前Plasma Debit的設計類似payment channel，每個coin的擁有者跟operator建立一個雙向的payment channel（提案中多處都在類比Lightning Network的channel，不過我不夠熟悉payment channel，就不在這裡提出比較），所以在交易時，都是透過operator做中介做交易。由於channel 結構上的問題，目前這個提案，只限於單一個operator。
More Viable Plasma
More Viable Plasm(MoreVP)是基於Plasma MVP作發展，改進提款的流程(Exit Game)。 上一篇Plasma MVP只有簡單介紹概念，沒有特別著墨在exit的部分，因為MoreVP是針對exit game的部分做改進，所以這次會對exit game的部分在做多一些的解釋。
在Plasma MVP中，有人要離開plasma chain（把錢提出）時，需要大家的簽章(confirmation signature)，而confirmation sign對使用者非常的不方便，每次有人離開，都需要收集簽章。但移除了confirmation sign，operator就很容易可以作怪，例如不打包使用者的tx（in-flight tx），甚至可以憑空鑄幣。MoreVP改變了原本離開plasma chain的排序機制，在MoreVP中越新的input（youngest input）有越高離開plasma chain的優先權。此外，挑戰期（challenge period）也改成兩段式。
整理一下：MVP的exit game 1. 越舊的UTXO的優先權越高 2. 送出交易需要簽章，離開時也需要簽章（confirmation signature） 3. 單一挑戰期（需要exit bond）MoreVP的exit game 1. 越新的input（youngest input）優先權越高 2. 只需要送出交易的簽章，不需要confirmation signature 3. 兩段式挑戰期（需要exit bond跟piggyback bond）
接下來再深入一點介紹兩段式的挑戰，這裡只針對worst case(byzatine共識且是in-flight tx)作討論，因為被打包的的tx不會有問題，就照正常程序離開即可。＊ in-flight tx: 還沒被打包的tx，無論是還沒被打包或是被operator惡意不打包。
當有人要離開plasma chain時，要先壓錢作擔保（exit bond），任何想一起離開的人需要壓附帶擔保（piggyback bond），如果沒有附帶擔保（piggyback bond）就不能離開。此時，進入第一階段挑戰期
第一挑戰期，原則上就是讓大家提出要離開的這個tx是不是無效的或被花過的。如果是，提出證明的tx‘ 來更換原本的tx，提出證明的人可以拿到上一個的附帶擔保（piggyback bond），然後壓上新的piggyback bond。然後一直直到沒人提得出新的證明為止。
若有人挑戰，就進入到第二階段
第二階段，上一階段只有提出挑戰，但是沒有人去確認，而這階段就是去確認／驗證第一階段的挑戰，如果驗證後是正確的，則第一階段的挑戰者可以拿到申請離開人的exit bond，並且申請著不能離開。若無人能驗證，則退還exit bond，此時申請者也不能離開（不能把plasma chain的錢提出）。 若第一階段無人挑戰，則有申請離開者就順利離開。 有沒有覺得聽完有點頭昏眼花 XD，這裡有提案者的圖解
source: https://ethresear.ch/…/ca4ff953b1fe258bc80dbb3ba98ad724d84d…
今天的介紹大概就到這邊，有任何的錯誤或是意見歡迎指教！
other references :Plasma Debit, SimplifiedLearn PlasmaOmiseGO-MoreVP
Originally published at kimiwublog.blogspot.com.
Ethereum Plasma Debit and More Viable Plasma was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
piggyback意思 在 Re: [課業][資通網路]關於壅塞控制與piggyback的疑問 的美食出口停車場
※ 引述《skywillnosky (Alfred)》之銘言：
: 1. piggyback 是在回應另一端時將DATA夾帶ACK回傳，
: 這是不是指雙方互傳的情況?(就是雙方互為收發方)
: 如果今天A端是單純的發送方，B端是單純的接收方，
: 那還會有piggyback嗎？
正常來說傳輸都是雙方都是收+送 那是參考書為了方便表達
所以只寫一邊 而每個TCP 標頭 有 6 flag 其中一個就是ack
當今天有資料要送 又順便要ack剛剛收到的
就會傳送資料 + ack flag=1
這就是所謂piggyback
而若單存發送方 那就一邊丟資料[用序號
那收方 TCP 標頭 ack FLAG =1 [但不消耗任何序號
回給他就好 這情況應該就不算piggyback
: 2. 雍塞控制在[快速回復]狀態有個
: if 一個dup ACK 抵達(有些只寫 "ACK抵達")
: cwnd = cwnd + 1
: 這段是甚麼意思？
: 收到ACK不是跑到雍塞避免嗎？
: cwnd = cwnd + 1 怎麼感覺好像是跑到緩慢啟動?
dup ack 就是你收到剛剛收過的同一重複序號 ack
在CA 或 SS 時 收到原本收過的序號 後來又收到三個重複同樣序號 ack
就會進入FS 就是快速回覆 而在進入快速回覆
又收到這個同樣的序號 視窗就+1
如果又收到就繼續++++
除非今天收到的ack 是新的序號才會跑回CA哦
當然time out 就是回SS拉
: 祝大家金榜題名
建議原PO可以去翻劉金順那本 裡面很多都寫得很詳盡
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.127.200.198
※ 文章網址: https://www.ptt.cc/bbs/Examination/M.1432998116.A.395.html
接收端收到到一個 序號 ack N = 1234
然後過了一段時間 又收到
1. ack n =1234
2. ack n =1234
3. ack n =1234 這三個就叫 dup ack
故我們現在收到 1個 ack + 3 個 dup ack
就進入 FS 了
而在FS 階段
有三種情形
1. 收到 ack n = 1234 >>>>>>> cwnd = cwnd +1 [每收到一個就+1次
2. 收到 ack n = 3456 >>>>>>> cwnd = ssthresh 回去 CA
3. 都沒收到任何東西 Timeout >>>>>> ssthresh=1/2(cwnd) cwnd = 1 進入SS
這是狀態機圖 不過很抱歉 剛好找到就是簡體字版本
https://images.51cto.com/files/uploadimg/20121231/1000082.jpg
※ 編輯: ko74652 (59.127.200.199), 05/31/2015 09:27:29
... <看更多>