再次汇总下之前我们讨论的内容。对于account + plasma，藏块问题应该是唯一需要解决的问题。其他问题都是有解且可行，只是解决方案实现的难度的问题。我们认为解决藏块有几种方案：
- 投票
- 增加退出顺序
- reveal block挑战
GluonPlasma的方案引入了投票机制，但是我们认为这种投票机制有两个重大的缺陷：1. 需要layer1有一种额外的资产和投票机制，链上投票本身会有很多问题； 2. 投票资产和layer2没有直接利益关联，没有太强的激励。
在此基础上，我们做了调整，引入了退出即投票的方案。
首先operator进行block submission的时候，只有上一个block等待超过了挑战周期后，才允许下一个block被提交，一旦新的一个block被提交，则可以认为上一个block已经被确认。
退出分为两种方式，一种为user通过在子链burn资产，然后将密码学证据提交到主链的正常退出。另外一种是halt exit，即认为是停链且从最后一个被确认的block进行状态退出。当前讨论的退出即投票的方案，使用的退出是halt exit。后续提到的退出，如无额外的说明和修饰均表示halt exit。
在挑战期间，允许用户提交退出，挑战。退出只能退出最后一个被确认的block，用户退出需要提供相关的密码学证据，这种退出属于”停链“退出，当用户认为在plasma chain中operator作恶或者藏块，且无法进行证明时，即可使用这种方法。此时用户提交”停链“退出时，会延长挑战周期。当有足够多的用户提交”停链“退出时，root chain将不再接受operator的block submission，且认为operator已经作恶，将plasma chain标记为halt。
当Operator在一定时间内，比如2 * 挑战期，一直未提交block也可以认为是Operator停链。
当在正常运行是，挑战期较短。用户可以通过在子链提交退出申请，”burn“资产，然后到主链正常退出。用户正常交易也可以得到比较短的confirmation latency。一旦Operator有作恶，如提交错误的block submission，或者错误的交易处理，用户这个时候可以提出挑战，挑战会延长confirmation latency。挑战成功则证明Operator作恶，此时链直接进入halt状态，所有用户以最后被确认的block开始退出，提交的halt exit也会生效。挑战失败后，不能证明Operator没有作恶，如果此时也没有足够的halt exit，则Operator可以继续提交block，确认当前最新的的block，一旦有新的block submission，则之前所有的halt exit投票失效。
vote tally不宜设置太高。太高则可能导致没有足够的用户在线，及时监测operator作恶或者主链的halt exit请求，而错过退出，导致operator作恶成功。如果设置偏低，最坏的情况是，恶意用户恶意退出，此时导致停链，所有用户退出即可。使用停链退出的方式，可以避免以下问题:1. 不会有massive exit的问题，用户可以在任意时间选择退出。但是如果被确认的块中已经有了恶意的交易，用户仍然存在风险，需要及早退出。2. 不需要所有人在线，只需要保证vote tally足够的人在线能够投票即可。
优势：
- 解决了投票时，需要额外的投票方案以及激励的问题，由layer2的用户自主到layer1去投票。
可能的问题：
- 对于account + plasma，如果引入checkpoint机制，则需要比较久的confirmation latency。utxo只需要operator提交block，用户确认过operator的block没有问题，且交易二次确认也被打包且block上链，则用户基本可以确认自己最终肯定可以退出。但是对于当前机制，由于引入checkpoint机制，在未发生挑战或者退出时，confirmation latency取决于最初的挑战周期，一旦有人进行挑战或者退出投票，则这个时间会变的很长，恶意攻击者可以就此进行攻击。由于攻击是有成本的（手续费），我们可以认为攻击者不会持续攻击，不会是常态。
- 如果operator已经控制layer2上过多的资产，则用户可能存在无法退出的风险。
- 如果没有足够的用户在线，用户的资产也可能丢失。这点在plasma mvp中也有这样的问题，如果作恶，用户不及时发现并退出，operator也会成功窃取用户资产。
另外一种解决藏块的方式是增加退出顺序。在plasma mvp中除了引入退出顺序之外还引入了二次确认机制，这样可以防止operator在打包交易时将用户的诚实交易放在恶意交易之后。
我们首先来讨论第一点，增加顺序。由于在account模型中，用户的storage有可能被其他用户修改。例如，对于ERC20来讲，对于用户的余额，其他人可以通过向用户转移一笔最小资金即可修改用户的balance。如果我们试图通过证明用户最后一笔交易，以及最后一笔交易处理后的storage，攻击者只需要转帐一笔很小的交易，就可以修改其storage。
让我们尝试去解决这个问题。
假设alice需要退出，提交她处理的最后一笔tx，以及tx处理后的event进行退出个人资产。bob挑战，提出关于alice资产的更新的交易tx2，以及event等。这个时候，由于bob的证明虽然可以证明alice要退出的资产不是最新的，但是由于其balance比alice要退出的资产要多，我们可以认为alice的依然是可以退出的。如果operator进行作恶，可以通过tx3将用户的资产变小，当operator提交证明alice资产不是最新，且大于operator提交的资产证明，这个时候alice可以向operator发起计算挑战。当然有可能operator在之前很早的一个交易就修改了alice的余额。而这个很早的交易可能是在某一个被藏的块中。由此可见我们在layer1使用大于/小于的逻辑，对资产那进行判断是有问题的，且这种方式要依赖特定的业务场景和合约类型。
我们采用另外一种方式，以用户最后提交的交易为准。这种情况可以避免上面的这种攻击。但是如果alice最新的balance是由bob转过来的，且是一笔正常的交易。这个时候alice就无法退出这笔最新的金额了。可见这种方式也有问题。
所以结论是无法增加退出顺序，除非在业务和模型上进行限制。如果进行限制那就有可能失去了使用account模型的优势，例如使用account模型实现utxo的交易？
reveal block是指，如果发生藏块，就可以用户提出挑战，然后operator必须提交真实的block，如果无法提交则对operator进行经济惩罚，且halt chain。这种情况下的问题是，由于layer2的block相对比较大，这个时候就需要将整个block reveal出来，手续费会比较高。如果由operator承担这部分手续费，就有恶意用户进行攻击。如果由用户承担手续费，则operator诚实出块，但是进行藏块，这种情况要求operator reveal，则operator不会受到任何惩罚。如果operator reveal block有问题，则operator会罚沒押金。假设在operator作恶的情况下，用户可以要求operator进行reveal，承担一部分费用，然后其他用户在需要有限时间内退出，否则由于reveal成本过高，好多用户放弃reveal block，而放弃layer2的资产。对于operator审查用户交易的情况，可以通过用户在主链申请退出，如果operator在一段时间内不处理则进行罚沒。这种方案，是需要user牺牲一定的layer1的reveal block费用，来保证所有人可以退出。