English
比特币现金(BCH)的循证流程
我如何设想比特币现金的分散合作模型
大家好，大家还不太了解我，我是一个对比特币“循证模型”发展十分着迷的人。在这篇文章中我将会向你们解释为何它如此重要，附上相关操作的例子。
基本原理
我从比特币区块大小争论时就开始思考，这场争辩中最出名的就是，有一部分占了上风，并结束了这场争辩，但不是基于自身的优势，而是基于对审查制度的反对。将来如何避免这样的情况发生呢？现在让我们一起来看看我们自身的优势。
我思考这个问题很久了，并在很多场合中简略地描述过，但我自己还没写出一个正式的文稿。我不情愿地说最近的事情，促使我做出了决定，但这并不重要：我想这个流程无论如何都有效的。
避免新一轮抓捕的关键就是建立一个分散式发展模型，因此没有一个人或团体被一个条约控制。但如何在一个分散的环境中建立合作呢？
开源原则很重要，但还不够。我们在这做的事，做的新尝试，是前所未有的尝试。只有我们才能开发出来。这就是我的提议的方向。
范围
在分散式环境中，我们乐见批评。我们都想要给世界带来点对点式的电子货币，但这究竟是什么以及怎样实现它，我们都有一点（或者很大）的分歧。
“循证模型”并不能解决所有分歧，但“循证模型”对技术问题有很大帮助。就技术的优越性进行评估，能有效消除许多分歧的敌意。比方说，如果你提供了一个可检验的证据，那么你的方案就优于我的，我就不得不让步。显然这不是一个建立共识的过程，但至少它选出了一方。因此，我认为这个方法可行。
这个程序主要为了共识变更。这是提议中最重要的部分，它需要最高级别的审查。其他非共识的变更提案也可遵循这个流程。
具体的变更（例如业绩变更）应属于个人/团队渠道，但任何人都可以根据自己的想法变通规则，我不是你的老板也不能阻止你。在这种情况下，一定要明确谁是你的对手（避免外界的干扰）。
流程
流程意在简洁，仅有几点要求。
进一步说，我们规定这一流程是为了达成共识的变更，也为了符合共识的精神，这一流程有意地放宽了。更具体地说，这不是一个严格的依次推进的流程。但就基本原则来说，这是最低要求。
0. 行动前：准备活动
吸引和寻找盟友/助手/雇员对变革达成一致很有帮助。尤其当你是孤军作战时，这就很有意义。
前提
整个系统对所有人都是适用的，不仅包括开发者。非技术人员也可以寻求或雇用技术人员来帮助他们（步骤 0.）。你在全程操作前不需要做任何准备。免许可的流程多么酷。
如果你想让提议生效，那么带头去做。这就意味着你得走出去说服那群喋喋不休的人，证明你的变更是有优点的。这么做的好处就是你可以按照你的节奏行事，而且一旦你按着这个步骤，他们也会愿意跟着你。恭喜你，你现在成了你的项目的领头人！
平台有意的避免有人带头的情况发生。许许多多平台，它要做的是保持公开和永久。如果你不确定公开的Git 仓库是否可行，那把它当成其他人接触你的平台也不错。
这并不意味着你在项目期间避免私交，换句话说，只有你与此项目有关的部分才需要全部公开。
1. 目标
明确变更目的或者需要解决的问题。你可以简单地描述，但要精确，为方便后期实施。这一步骤也被称为“问题阐述”。每次明确修改问题的范围，这是很重要的（有意义时才做）。一旦问题被提出，应该为可行性方案定个明确目标（即：不要目标太高）
同样地，划清目标的界限，与非目标区别开来也很重要。
目标的设定是很重要的，这样每个人才能在开始之初站在同一起跑线。即使解决方案尚未明晰，也可以设定目标。遇到请求评议（RFC）这一类时，你应该检查一下上述的步骤O.，这会让你更顺利的。
2. 解决方案
既然你确定了一个目标，那么你就要提供一个解决方案。每个问题都可以用多种方式解决，你应该多方考虑，包括其他人的替代方案。
尝试探索利弊和得失：变更都会伴随着得失。真诚地对待得失会让你的项目更具有说服力。
事实上，你要做好心理准备，最终方案不一定是你提出的那个方案。但你不会因为这一点而失去主动权；相反，你通过接纳他人有益的提议（有依据的）来展现和巩固你的领导能力。
3. 计划书
不言而喻，共识层面的变动需要独立于语言（编程语言等）的正式计划书。计划书应具备精确性，指导性和可行性，每个人都可以根据计划书展开接下来的工作。这一点专门用一个单独的段落来强调。
4. 实践
提供一个参考代码供测试。这并不意味着您需要为每个团队免费编写代码，您只需要提供一个参考代码来测试，并允许其他人用它来测试。
技术操作对大多数人刚开始来说都很困难，但是！如果你自己做不了，你可以雇佣其他人来为你服务。这也是一个为比特币现金吸纳人才和传播相关技术的途径。
如果有足够的吸引力，人们会免费为你服务的，要知道开发人员别无选择。
5. 证明
提供一个利于变更的确切理由，并提供可复现的证明（可以是测试套件）。论证环节毋庸置疑是循证模型中至为重要的一个环节，它能有效地说服别人认可提案。在适用的情况下，最好提供语言无关的代码数据供测试。需要根据测试和数据验证代码的有效性。
你会听到批评的声音。我们可以理解人们都希望做到最好，而您的第一次方案可能还做不到。此外，你可能会遇到竞争对手；对于竞争方案，他们要为自己辩护。为了展现优势，您的论据要有可比性。您应该在合理的范围内对比其他解决方案（以及它们与您一起对比）。因为领导者就是这么做的。
解决方案的竞争是很重要的，竞争对手也有他们的领头人。你什么也做不了——因为整个流程都是免许可的。我们来这是为了找到最佳方案。就让事实说话吧。
6. 反馈
为完善上述各项应收集反馈。不单是接触社交媒体，还应该关注个体活动。如果他们不发评论，那就很奇怪了（因为开发人员通常别无选择）。你如何处理这些反馈是你自己的事。你可以通过反馈改善计划书、代码和基于它的测试。或者不考虑反馈，那也没关系。
显然，你应该尽早地持续接受反馈。如果你还没有，那是时候开始了。确保和系统中的所有参与者联系，并对他们的成本/收益进行评估。你肯定会遗漏某些部分，因为你不是：用户、矿工、协议开发人员、脚本开发人员、钱包开发人员、服务人员、交换人员和商人。与各方接触会提升你的洞察力，并维护你的变更。总的来说，这和发邮件或发短信一样简单。
7. 评估
为评估和提出替代方案预留充足的时间。如果这个想法太新颖，就需要花时间来说服人们，并单独检验论据。
我们都希望我们的新点子能被接纳，如果没纳入，我们就会不耐烦了。但一旦其他人都认识到它的优点，它最终就会实现，尽管要花些时间。另外，如果其他人想提出一个竞争方案或者代码，也花时间。尽管如此，我们仍要鼓励他们表达观点。
此外，可能还有更紧急的事情在处理中。系统要在一年中处理非常多的共识变更，因此您最好与其他参与者定好要完成的事，并做好变更推迟的打算。
多长时间是合理的呢？多长时间都合理。当共识建立后你就会知道要花多少时间了。不要强求也不要消极。
后记
虽然这些步骤看上去一般，但要建立一个循证流程，上述步骤都不可或缺。这些步骤不必依次完成，尤其当竞争方案出现时，而且肯定会要重复多做几次。
再次强调，如果你的方案不是最终采纳方案，但你仍然是项目的领导者。这一切基于优势比较，你应该庆幸找到了最佳方案。
传递接力棒
可能由于某些原因，该项目的领导人无法完成它。有时候现实生活会狠狠地打击我们！有时候公交车也会罢工，我们没法预知一切。
如果领头人要转交责任，他们可以在公开场合下完成；他们可以自愿讨论交接的细节。如果领头人不知不觉地消失了，其他人也可挑起担子，但前提要真诚地伸出援手。最好领导者一开始就推荐一个接棒者，以防意外发生。
评价
这个流程针对新的捕获建立一个松散的框架。它为每个人提供了一个公平竞争的环境。每个人都需要提供同等质量的证据来支撑变更，没有人例外。无论是我，中本聪，新来的或是有经验的开发者都一样。我们要求每个人都遵守同样的（高）标准。
我们不能百分之百地避免被抓，尤其是那些印超多钱并制造暴力威胁的参与者。但肯定的是，地狱让他们生活更艰难。
有一个粗略的变更流程会降低新人参与的门槛。他们不需要“建立好名声”，只要提出有力的观点，并提供充足的证据，这样才能供人评判。
你不要因此期望赢得别人的喜欢。事实上，人们会讨厌你，但仍然会根据你的付出认可你的成绩。会有厌恶！（但这种情况不会持续下去，但如果有人恨你，那你需要反省一下）
这个框架显然不是“一次过”。你不能因为你完成了所有的步骤就期望方案实现。谁能接手大项目，就是能做决定的人。这并不代表我们不重视那些有能力的人，相反，我们会给他们应得的荣誉，只是他们不能得到免费的通行证。
你的贡献可能会被忽视。可能是没有人对此感兴趣。例如，如果您主张减少区块限制，即使您提供了一个方案，它也不会被合并进来。真倒霉！
其他时候，可能是你没有很好展现出来。如果你认为它有价值，试着表达。可能是因为它太突破了，以至于人们根本就没有意识到。
很明显这是有权衡的。可以理解的是，这将比集中协议慢。我认为这是接纳时的考量。我不需要新的捕获，也不需要巴士指数为1（意为团队协调性最好）的协议。
有句老话说，“一个人走得快，一群人走得远。”我更想走得远。
这个流程提供了一个解决技术分歧的框架，但显然不是所有的分歧都是技术问题。对我们来说，只要过程合理，我们就可以一起努力。但如果存在无法克服的分歧，那么保留分歧也是一种选择。
也可能出现这种情况：一些恶意的参与者接管了几个开发团队并阻拦其发展。我们确实要为此做好准备，因为区块大小争论已出现了类似情况。那样的话，我们就要把他们分开。拆分始终是一种选择，即使可能是最后的选择。
我希望，从今往后，这一流程能有助于最小化降低分歧。
