Posts made by eosforce

eosforce

中文

开发进展

上周开发团队github 28 次提交。

Codex.io修正合并eosio 2.0.x版本带来的问题, 测试Codex.io 2.0.x 新特性的适用程度。
完善EOSC及Codex.io单元测试。
调研Codex.fc支持不同加密算法开发方案。
调研EOSC链上链下数据索引查询方案。
Codex.io重构链启动过程设计, 删去创世合约的依赖。
Codex.io添加合约账户静态声明功能。

社区动态

EOSC主网去中心化预算系统首个提案预算已经发放到申请人账户。
EOS原力成功入选CoinEX验证节点，排名16位。
EOSC 第一届预算委员会（EDBS-1）第六次会议召开。
EOSC社区全新官网上线，将朝去中心化的高性能智能合约平台的方向持续演进。
原力技术团队与顺丰区块链研究中心进行区块链应用落地深度交流。探讨商品溯源、供应商金融、隐私计算、数据存证、清算结算等领域的区块链解决方案。

周报解读

本周，EOSC社区新版官网上线，新版官网为用户提供了预算提案入口，展示主网和预算系统相关的数据；同时，用户还可以通过EOSC社区新版官网查看所有主网改进提案和已通过预算提案。

Codex.io删掉了在链启动过程中对创世合约的依赖，优化了链的启动过程，使Codex.io的启动更加轻捷。

下周工作

完善Codex.io与EOSC交互开发支持, 实现链交互API轻节点.
设计Codex.fc支持多种哈希算法支持方案
调研Codex.io基于Golang运行时运行链方案
实现Codex.io合约账户静态功能, 并调研EOSC对其的适配情况。
完善Codex.io单元测试。

English

Work Completed

The development team completed 28 submissions on Github.

Fixed the problems with Codex.io merged with eosio 2.0.x, tested the applicability of new features in Codex.io 2.0.x.
Improved the unit test of EOSC and Codex.io.
Researched the development plan of Codex.fc supporting different encryption algorithms.
Researched EOSC data index query scheme.
Redesigned the chain startup proces of Codex.io, removed the dependency of the genesis contract.
Added a declaration feature of the contractual account on Codex.io.

Community News

The first proposed budget of EOSC Maine Decentralized Budget System has been issued to the applicants account.
EOSForce successfully ran for CoinEx verification node, ranking 16th.
The 6th meeting of EOSC 1st Budgeting System (EDBS-1) was successfully held.
The new official website of EOSC community launched, evolving towards the decentralized high-performance smart contract platform.
The EOSForce technical team and SF Blockchain Research Center had an in-depth communication on commercializing blockchain applications, discussing about blockchain solutions on commodity origins, supplier finance, private computing, data access, and transparent payments.

Interpretation

This week, the new official website of the EOSC community, the new official website provides users with a budget proposal entry, showing the data related to the main network and the budget system. At the same time, users can also view all the main network improvement proposals and approved budget proposals through the new official website of the EOSC community.

Codex.io removes the dependency on the creation contract during the chain startup process, optimizes the chain startup process, and makes Codex.io boot faster.

Next week's plan

Improve the support for the interactive development of Codex.io and EOSC to realize API light node with chain interaction.
Design the support plan for Codex.fc supporting multiple hash algorithms.
Research the chain-running solution of Codex.io running based on Golang.
Implement the static declaration feature of the contractual account on Codex.io, and research the adaptation of EOSC to it.
Improve Codex.io unit test.

eosforce

EOSC主网去中心化预算系统首个提案预算已经发放到申请人账户。

由超级节点Awake发起的EOSC主网去中心化预算系统首个申请提案《EOSForce BP管理平台DAPP》预算已经在14401927区块高度发放到申请人账户。

提案链接：https://u.eosforce.io/#/motion_item/0

去中心化预算系统来自区块奖励的30％代币，不做总量限制，旨在支持EOSC生态发展，任何人可以发起申请预算提案。去中心化预算系统有单独的账户权限，账户权限归系统所有，审批权归管理委员会所有。

BM：近期致力于研究短期内优化Rex和CPU价格问题的解决方案

BM发推表示，其团队近期一直在寻找解决方案，旨在优化Rex问题和更普遍性地解决CPU价格问题。同时，他表示：期待跟大家分享讨论成果，并强调EOSIO会变得更好，因为其团队在不断攻克这些挑战。

EOSC 第一届预算委员会（EDBS-1）第六次会议成功召开

北京时间2019年11月19日，EOSC 第一届预算委员会（EDBS-1）第六次会议成功召开，本次会议达成了以下共识：
1、金马老师的文章《为什么 EOS 要借鉴第一个分叉链 EOS 原力？| EOSC》效果不错，作为首个宣传类的提案，全体委员一致同意审批。

2、EDBS组建EOSC预算系统交流微信群，集中讨论预算系统相关的事件。主要收集用户在使用系统时遇到的困难，以及对预算系统发展方向的探讨。

3、BiBox二周年活动，预算委员会将代表社区为BiBox打call，已筹借10万EOSC作为第一期活动费用，后续根据活动的具体效果，再决定是否追加活动经费；预算委员会将会第一时间同步活动信息至EOSC社区成员。

4、EIDOS合约开发教程，初步方案为面向EOS开发者和EOSC开发者，将此次活动的开发者聚集到开发群，方便后续引导到EOSC主网上开发。活动分三个奖项，共计10万个EOSC的奖金。

Aloha EOS：执行区块生产者协议移除不合格BP

近日，Aloha EOS 向社区提交了一份提案，即根据《区块生产者协议》的第六条，区块生产者“将提供功能齐全且可查询的公共P2P和API端点。

当前的备选节点中有一些商未与公众共享任何API或P2P端点信息，Aloha EOS 建议将这些节点将在备用清单中被删除，当前已发布了对应的系列多签提案“ rmvproducer ”。如果这些节点在批准提案之前更新帐户以显示网站和API / P2P端点，Aloha EOS 将取消提案。

BM：在发布Voice之前仍有很多需要解决的问题

据EOS GO消息，BM 近日在弗吉尼亚理工大学举办的2019年的 Blocksburg峰会上表示：在发布Voice之前仍有很多需要解决的问题。不光是要考虑到技术，还要考虑到法律以及其他。因此，不是所有的事情都能一步一步发生在我们的计划时间表中。我目前能够透露的是，我们在代码方面已经准备好了一些很棒的内容，在监管机构方面也取得了出乎意料的进步。

EOS原力PC钱包新版本发布

EOS原力PC版钱包v1.1.257版本已经发布，本次更新主要修复纯数字账户余额显示问题和定期投票显示问题。

更新方式：(二选一)

打开PC钱包可自动更新版本。
下载地址：https://github.com/eosforce/wallet-desktop/releases/tag/v1.1.257

eosforce

中文

开发进展

上周开发团队github 40 次提交。

Codex.io合并eosio 2.0 rc版本。
调研eosio 2.0.x 新特性在EOSC中的适用程度。
完善EOSC单元测试, 添加EOSC功能对应的测试用例。
开发EOSC半节点。
移植history_tools以适配EOSC。
调研filecoin项目进度。

社区动态

EOSC 预算委员会（EDBS-1）第五次会议召开，将组织开展IDE开发教学活动。
由forcesphere节点发起的BP漏块惩罚多签通过，发起节点和多签节点将分配该节点所有积累罚金。
Coingecko更新EOSC公链项目排名，目前市值排名448名。

周报解读

本周，EOSC开发团队调研了EOSIO 2.0.X 的新特性在EOSC中的适用程度，判断哪些新特性适合加到EOSC中。

本周开发团队还移植了history_tools以适配EOSC。history tools是一个查询历史数据的工具，通过history tools，开发者可以更加高效灵活地完成对EOSC历史数据的查询。

下周工作

EOSC合并eosio 2.0 rc版本, 测试eosio 2.0.x 新特性在EOSC中的适用程度。
完善EOSC及Codex.io单元测试。
整理EOSC文档系统, 完善文档分类和框架。
基于目前简单版本的EOSC轻节点开发Codex.io区块头验证节点。
设计并规划Codex.io无Token模式开发方案。
调研Codex.io支持国密算法开发方案。

English

Work Completed

The development team completed 40 submissions on Github.

Merged eosin 2.0 rc with Codex.io.
Researched the extent to which new features are applicable in EOSC.
Improved support for EOSC unit test, added test cases corresponding to the EOSC function.
Developed EOSC half-node.
Transplanted history_tools to adapt EOSC.
Researched the progress of the filecoin project.

Community News

The 5th Meeting of EOSC Budgeting Management Committee(EDBS-1) was successfully held, and it will organize IDE development teaching activities.
The multi-sig for BP block-missing penalty proposed by forcesphere node was passed, and the proposer and the multi-sig nodes will allocate all accumulated penalty.
Coingecko updated the ranking of EOSC, currently ranking 448 in market capitalization.

Interpretation

This week, the EOSC development team investigated the applicability of the new features of EOSIO 2.0.X in EOSC and determined which new features are suitable for adding to EOSC.

This week the development team also ported history_tools to adapt to EOSC. The history tools is a tool for querying historical data. Through the history tools, developers can query the EOSC historical data more efficiently and flexibly.

Next week's plan

Merge eosio 2.0 rc to EOSC, test the extent to which new features of eosio 2.0.x are applicable in EOSC.
Improve unit test of EOSC and Codex.io.
Collate EOSC document system, improve document classification and framework.
Develop block header verification node based on the current simple version of the EOSC Light Node.
Design and plan Codex.io no Token mode development solution.
Research the development plan of Codex.io supporting the national secret algorithms.

eosforce

Block.one 发布 EOSIO 系统合约 v1.8.1 修补短账号竞拍挖矿漏洞

11月13日，Block.one 已发布 EOSIO 系统合约 v1.8.1，修改了短账号竞拍规则，即：系统帐号退回之前以较低的出价的转账交易的CPU将不再有 eosio 承担，修改为投标成功者的账号承担 CPU/NET 。同时，Block.one 也发布了 EOSIO 系统合约 v1.9.0-rc2 。

EOSC创始人孤矢：广义区块链的三个计算时代

2019年11月10日，在抹茶「Parallel Cities 平行城市」杭州站中，EOSC创始人孤矢作了「广义区块链」的主题演讲。对于广义区块链的相关技术，孤矢从「区块+链、共识算法、虚拟机、跨链/分片、TPS、隐私、协议处理、EOSC」等方面做了详细阐述。

谈及目前三个计算时代，孤矢表示，比特币-计算器时代面向特定应用，它用来交易/存证，以太坊/EOSIO-计算机时代面向通用计算，它具有交易、存证、存证规则，以及高性能的特点，而COSMOS云计算时代，它拥有容量可拓展，多功能组合，统一的记账方法，以及TCP/IP等性能特征。

Block.one将参与EOS主网投票推动EOS健康发展

11月13日，Block.one发文宣布，开始参与EOS主网投票。此前，Block.one CEO 曾表示，在b1所持有的EOS跟主网当前的总投票代币占比不大时，Block.one或许开始参与主网投票。如今，Block.one持有的EOS少于总流通量的9.5%，并随着通胀这个比例会越来越小。Block.one宣布，准备开始发挥应有的作用，重点是继续支持EOS网络的健康升级，以实现这些目标的迭代改进，而全球监管机构强调的目标是最大程度地分散权力。

EOSC 预算委员会（EDBS-1）第五次会议召开

EOSC 预算委员会（EDBS-1）第五次会议召开，并将组织开展IDE开发教学活动，帮助更多开发者在EOSIO生态上进行开发。

BM：EOSIO 2.0 可以给 EOS 网络性能带来 5 倍增长

11月12日，BM表示，EOS 网络已经连续几天保持在 578 TPS，而这只是出了"几成功力"而已，就远远超过其他活跃度 top 5 的区块链的最佳 TPS 之和。而这，还是在 EOSIO 2.0 未正式部署之时，EOSIO 2.0 可以给 EOS 网络性能带来 5 倍增长！

Block.one 已发布 EOSIO v2.0.0-rc2

11月8日，Block.one 发布了 EOSIO v2.0.0-rc2，该版本是 EOSIO v2.0.0 的一个候选版本，当前的最新发行稳定版为 v1.8.5。
EOSIO v2.0.0-rc2 版本涵盖了一些安全补丁以及其他方面的修复：
1、安全补丁：修复了与 EOS VM 相关的一些bug，运行着 v2.0.0-rc1 的节点需要尽快更新。
2、稳定性补丁
3、更新须知：从早期版本、v1.8.x 以及 v2.0.0-rc1 更新到 v2.0.0-rc2 需要注意的事项。
4、其他一些零碎修改。

eosforce

EOS是一款以“降低开发者成本，让用户交易免费”为目标的公有链。也就是说用户在交易中，不需要收取交易费。为了做到这一点EOS设计了CPU、NET和RAM三种资源。用户在拥有这三个资源之后才能免费交易。但是绝大多数用户来说分不清这些资源是什么。尤其在近期EIDOS活动中，很多用户的CPU质押不足，导致无法转账。这究竟是为什么呢？本文将详细讲解EOS中的CPU究竟是什么？以及CPU资源设计背后经济原理。

什么是CPU资源?

我们在EOSIO上每一次交易时，我们的这笔交易数据会被超级节点（BP）们执行和检查,超级节点在执行这项工作时需要花费计算时间。我们把这个所需要计算的时间的资源称之为CPU。所以CPU是指节点在处理、验证交易时必须花费的执行时间，EOS中CPU以微秒（μs）为单位。因为每个节点使用时间是有限的。为了合理使用每个超级节点的计算时间。EOS设置了一套CPU资源的使用模型。

资源如何分配？

我们知道了，CPU是节点在处理、验证交易时必须花费的执行时间。在EOSIO中, 用户为了使用CPU资源可以使用EOS抵押来获取CPU, （第一次注册的账户将自动购买一定比例的CPU资源，这也是为什么EOS账户注册需要收费的原因）。这个抵押过程相当于用户买了超级节点的一部分运算时间,那么 EOS中CPU资源是如何分配的呢？这里我会把背后的原理进行详细论述，想看结论的直接跳至最后一章。

为了方便大家理解我们这里来做个类比，我们把EOS交易类比成火车运货。

首先，我们想一想，这列火车是否可以免费运货呢, 如果这样就可能有用户不停的发送大量的垃圾到B地, 这样其他人就用不了这列火车了, 不能免费就要收费, 既然收费, 就要有个定价的方式。

假设从A地到B地有一列火车, 每10分钟一班列车, 每个列车上能装10吨货物, 用户使用列车从A地到B地发送货物（我们先忽略装车和卸车的时间和列车的空间）。

首先最简单的定价方式，就是确定每吨货物需要多少钱, 如果定每吨100元钱, 那么一个用户如果需要运3吨货物到B地, 那就需要支付300元运费。这么做有什么不足之处吗？有的。如果如果当前需要运输货物的需求很少, 那么货运火车就会空跑, 此时火车的运力就浪费掉了, 不如减价吸引更多的用户发货. 其次如果当前需要运货的用户很多而发生了拥堵, 那此时着急发货的用户也会想要多支付一部分运费来使得自己的货物可以更加快速的发到B地。

这种方法其实就是类似于以太坊的手续费模型, 在以太坊中每笔交易需要支付手续费, 用户可以自行确定自己的费率, 此时矿工就可以根据费率来选择打包那些用户的交易。

EOSIO是如何设计的？

在EOSIO中, 用户为了使用CPU资源可以使用EOS抵押来获取CPU。类比一下就是火车的管理者印发了一些“运费券”。

假设每张运费券可以运送10千克的货物, 用户要想发货那么就要得到一些“运费券”,用户把“运费券”给火车的列车员, 这样列车员就会有很多“运费券”,当然列车员为了支付火车的成本, 会把“运费券”卖给用户, 完成循环.。但是考虑到火车的运力将会随着技术的发展而不断增强, 这也就意味着按理说“运费券”的总量应该不断增多, 而价格应该不断下降, 否则用户就没法享受到技术发展而带来的好处。另外, 如果“运费券”的价格因为某些原因增长的很多, 类比EOSIO就是如果EOS的价格增长了(这显然是很多人所希望的), 如果此时每张“运费券”所等运送货物的重量没有增长, 那就会反过来导致原来的用户支付不起运费, 这显然是不合理的, 因为列车员得到了更多的收益, 此时他就会升级自己的火车来运送更多的货物, 但是如果是固定的“运费券”, 那就会导致运力上涨了但是用户却用不起火车, 另一方面, 有些时候“运费券”的价格会下降, 那么会导致火车的总运力下降, 此时会出现“运费券”无法使用的情况。

EOSIO采取的是基于使用权的资源模型, 从上面的叙述中可以得出“运费券”所对应的重量应该是浮动的, 这个值即和当前的需求总量相关, 也应该和供给总量相关。

为何会CPU不足？

这时就有一个问题: 如果Alice一次要运5吨货物怎么办, 如果简单的要求Alice抵押更多的“运费券”,那么如果Alice要抵押的“运费券”就会十分多, 多到大多数用户没法承受, 另外考虑到大多数时间火车都不是满载的, 让Alice多放些货物也无所谓。顺着这个思路, 火车的管理者提供了一个“折扣率”的东西, 如果现在是1折, 那就意味着Alice可以运10吨的货物, 如果当前火车比较空, 那么“折扣率”就可以很优惠, 如果火车运的东西很多, 那么“折扣率”就不能太优惠, 最终如果火车一直很满, 那就不应该打折, 所有用户只能按照自己的实际份额运货。

EOSIO中有一个叫做virtual_cpu_limit的数值, 这个数值就是这个“折扣率”, 当然EOSIO中这里是以用户CPU资源的倍率来表示的, 恶意使用优惠的账户会被列入“灰名单”中, 这时这个账户是无法享受到“折扣”的。

总结

所以，综上所述，我们知道CPU是指节点在处理、验证交易时必须花费的执行时间，而CPU的资源是采取的是基于使用权的资源分配方式，使用比例根据总抵押比例进行调整。简单的说，如果整个EOS网上有1000个代币被抵押在CPU上，而我的账户抵押了20个，那么我保证会拥有CPU总容量的2％的使用权。同时，平时我们使用的CPU在空闲状态下都是通过折扣率享受的优惠状态，而在EIDOS这次的情况下，CPU突然使用暴增，随之而来的折扣率也低了。所以在同样的CPU抵押下能够使用的计算资源变低。从而导致CPU资源不足。

这解释了为什么BM在EIDOS事件上的那句话：抱怨当前主网的CPU紧缺状态是没必要的，这就跟抱怨Uber用车高峰期打不到车/车费溢价的道理一样。不要抱怨市场通过提高价格来平衡供求，要关注实际总供给。

eosforce

中文

开发进展

上周开发团队github 21 次提交。

测试EOSC Token Exchange合约, 根据社区反馈进行优化。
完善EOSC单元测试, 添加EOSC功能对应的测试用例。
整理EOSC文档, 添加新特性相关的文档。
开发EOSC半节点框架: 完成Chain框架设计。
完善EOSC goeosforce库, 添加新特性支持。
调研history_tools对EOSC的适配方案。
调研filecoin项目进度。

社区动态

孤矢受邀参加CoinEX上海行活动，探讨CET社区建设，共同推动区块链应用落地。
孤矢在参加由B-LABS主办的《数组经济时代下的区块链动能论坛》活动上做了《Libra、央行数字货币的格局之争》主题演讲。
EOSC社区举办社群主题分享活动第一期和第三期，社区成员针对当前社群热点话题进行分享和讨论。
EOSC目前已与EOS Tribe和StartEOS达成初步生态以及钱包合作共识。
超级节点Awake开发EOSC小白开发工具, 方便开发者更好的对开源社区作出贡献。
原力团队参与filecoin验证,获得早期测试资格。
EOSC创始人孤矢参加抹茶Parallel Cities平行城市活动，并发表广义区块链主题演讲。

周报解读

本周，EOSC开发团队继续完善EOSC单元测试，并添加了多项EOSC功能对应的测试用例。通过对EOCS已有功能、新功能的全局测试，确保新功能的安全可靠，提高主网的运行稳定性。

Awake节点团队开发出EOSC Web IDE开发工具，降低EOSC开发者进行智能合约开发的门槛，提高开发效率。

下周工作

EOSC合并eosio 2.0 rc版本, 调研新特性在EOSC中的适用程度。
完善EOSC单元测试, 添加EOSC功能对应的测试用例。
整理EOSC文档, 添加新特性相关的文档。
继续开发EOSC半节点。
录制EOSC DAPP开发课程。

English

Work Completed

The development team completed 21 submissions on Github.

Completed EOSC Token Exchange contract, coordinate with the community to start the test.
Completed EOSC Token Exchange data query plugin.
Improved support for EOSC unit test, added test cases corresponding to the EOSC function.
Collated EOSC document, added document related to new features.
Complete the technical document of EOSC’s first sub-chain plan, designed cross-consensus prove mechanism.
Built EOSC half-node framework, tested the performance of EOSC half-node.

Community News

Cyborg was invited to attend the CoinEx Shanghai Meetup to discuss the construction of CET community and jointly promote the implementation of Blockchain DApps.
Cyborg made a speech of The Aspiration Competition between Libra and DCEP at the Blockchain Kinetics Forum in the Era of Array Economy hosted by B-LABS.
The EOSC community organized the first and third phases of the community theme sharing event, at which community members share and discuss current community hot topics.
EOSC has reached a preliminary ecological and wallet cooperation consensus with EOS Tribe and StartEOS.
The Awake Node developed an EOSC development tool for beginners, which facilitates developers to make contributions to open source community.
The EOSC team participated in the filecoin verification and got an early test qualification.
EOSC founder Osawa participated in the parallel city event of Matcha Parallel Cities and presented a keynote speech on the general blockchain.

Interpretation

This week, the EOSC development team continued to improve EOSC unit testing and added multiple test cases for EOSC functions. Through the global testing of the existing functions and new functions of EOCS, the new functions are ensured to be safe and reliable, and the operational stability of the main network is improved.

The Awake node team developed the EOSC Web IDE development tool to reduce the threshold for EOSC developers to develop smart contracts and improve development efficiency.

Next week's plan

Merge eosio 2.0 rc to EOSC, investigate the extent to which new features are applicable in EOSC.
Improve support for EOSC unit test, add test cases corresponding to the EOSC function.
Collate EOSC document, add document related to new features.
Develop EOSC half-node.
Record the EOSC DAPP development course.

eosforce

Web IDE是什么？

各位小伙伴对IDE肯定不陌生，主要是用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具。

web IDE则是将IDE里面除用户交互之外的功能全部移到了后台，开发人员在浏览器上可以像在本机一样调试、编译、运行程序，并且不会受系统环境和机器性能的限制。

（图为一款web IDE的系统架构）

目前的web IDE主要有AWS Cloud9、Cloud Studio、Eclipse Che、Gitpod等，这些web IDE各有千秋，其中Gitpod是目前web IDE中对Github上的项目支持最好的，也是eosio主推的一款产品。并且Gitpod对于非商用的开发者，每月会有100小时的免费使用时间，本文的讲解，也会以Gitpod为例（下文中提到的web IDE，在没有特指的情况下，全部为Gitpod）

关于Gitpod，可以参考Gitpod说明文档。（https://www.gitpod.io/docs/）

为什么要使用Web IDE

EOSForce社区小伙伴在EOS Web IDE上线的同时，第一时间发布了EOSC版本。方便了开发者更好的对开源社区作出贡献，接下来将详细讲解使用教程。

1. 环境搭建及运行节点门槛

对于很多区块链爱好者来说，想要搭建一个简单的环境来了解一个区块链项目，很大程度上会因为搭建环境以及初次运行过程中的各种问题而退缩。

对于智能合约开发者来说，很多时候会因为初次运行，或者环境切换等原因，在这个过程中耗费很多不必要的时间成本。

而Web IDE的出现，会让这些问题不再成为麻烦。拿eosio来说，想要启动一个节点，并且在节点上部署开发好的智能合约，并不是一件很简单的事，需要下载代码、安装依赖、编译代码、启动节点、编译合约、然后部署。在这个过程中，可能会出现非常多的问题。

EOSIO 2官方更新后，使用Web IDE，只需要一键，就可以开始开发调试智能合约，消除开发人员的入门障碍。它在云中运行，使新开发人员能够建立智能合约和Web应用程序开发环境以及完全集成的单节点个人测试网，因此他们可以在几分钟之内从入门到构建。

2. 启动节点的机器性能要求

在计算机上运行一个eos的节点，是非常耗费性能的，很多PC机可能根本没法成功运行一个eos的节点，更不用说同时还打开IDE调试智能合约，而Web IDE将这些对机器性能的要求移到了后台，前端仅仅是一个交互页面。

3. 随处可用

传统IDE还有一个问题就是每次开发必须带上开发机或者每次改完代码都push到远程，而Web IDE解决了这个问题，它可以随时在远程保留开发环境，随时随地，只要有浏览器，就可以开始写合约。

以EOSC为例讲解使用步骤

1. 浏览器插件下载

Gitpod对Chrome和Firefox都提供了插件支持，下载插件后，会使进入Gitpod开始开发更加方便，本文以Chrome为例介绍使用步骤。

Chrome插件下载：https://chrome.google.com/webstore/detail/gitpod-online-ide/dodmmooeoklaejobgleioelladacbeki

2. 一键生成环境

插件下载成功后，打开eosforce专门为使用web IDE开发智能合约准备的github项目eosforce-web-ide，我们会发现项目的主页上多了一个Gitpod按钮。

点击Gitpod按钮，就可以直接进到一个节点已经启动好的环境中，并且这个环境提供了一些编写智能合约的模板（实际的开发环境中，建议大家先fork这个项目，然后再启动Gitpod）。

如果没有安装GitPod插件，可以直接在浏览器上新开一个页面，输入网址 https://gitpod.io/#https://github.com/xxxxx/eosforce-web-ide (其它xxxx替换成你的github用户名)

从图中可以看见，eosforce已经模拟正式环境启动了23个节点并且正在出块，同时整个编写智能合约的IDE环境已经搭建好，现在就可以使用web IDE直接开始开发智能合约了。

3. 开发调试合约

智能合约的具体开发、调试以及部署说明可以参考eosio白皮书，本文仅分析该项目模板合约的部署和调用。

在web IDE中打开contract/talk/talk.cpp文件，核心逻辑如下：

[[eosio::action]] void post(uint64_t id, uint64_t reply_to, eosio::name user, const std::string& content) {

message_table table{get_self(), 0};

require_auth(user); // 检查用户

if (reply_to) // 检查是否需要回复

table.get(reply_to);

// 检查id不能过大，并且当没有传的时候分配一个id

eosio::check(id < 1'000'000'000ull, "user-specified id is too big");

if (!id)

id = std::max(table.available_primary_key(), 1'000'000'000ull);

// 记录post的内容到table

table.emplace(get_self(), [&](auto& message) {

message.id = id;

message.reply_to = reply_to;

message.user = user;

message.content = content;

});

}

理清post方法的逻辑之后，就可以开始编译文件了，首先点击Gitpod上方导航栏的Terminal -> New Terminal(如下图)

可以看见Gitpod下方出现了一个新的命令行窗口

在该窗口执行如下命令，编译talk.cpp文件，会生成talk.abi和talk.wasm两个文件

eosforce-cpp contract/talk/talk.cpp

然后执行以下命令，创建合约账户talk，并向该合约账户转帐10000EOS(此次转账主要是该账户随后需要set code和set abi)

cleos create account eosforce talk EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV

cleos transfer eosforce talk '10000.0000 EOS'

通过执行系统合约为talk账户租一定的内存(此处需要多租一点，因为set code操作需要的内存很多)，然后将编译后的wasm和abi文件绑定到talk合约账户

cleos push action eosio vote4ram '[talk, biosbpa, "2000.0000 EOS"]' -p talk

cleos set code talk talk.wasm

cleos set abi talk talk.abi

随后创建两个普通账户bob和alice，并向他们每人转帐100 EOS(因为后续执行合约需要扣除fee)，用来执行合约

cleos create account eosforce bob EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV

cleos create account eosforce jane EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV

cleos transfer eosforce bob '100 EOS'

cleos transfer eosforce jane '100 EOS'

为talk合约账户的post方法设置fee，此处是其他账户执行该方法时需要支付的fee

cleos set setfee talk post '1.0000 EOS'

执行合约，以下三个命令分别是

bob以1000为id，发布一条"This is a new post"消息到table，并且不需要回复

jane以2000为id，发布一条"This is my first post"消息到table，并且不需要回复

bob以1001为id，发布一条"Replying to your post"消息到table，并且回复jane

cleos push action talk post '[1000, 0, bob, "This is a new post"]' -p bob

cleos push action talk post '[2000, 0, jane, "This is my first post"]' -p jane

cleos push action talk post '[1001, 2000, bob, "Replying to your post"]' -p bob

最后，输入如下命令，查看table的内容

cleos get table talk '' message

得到如下结果，说明合约已经成功执行

{

"rows": [{

 "id": 1000,

 "reply_to": 0,

 "user": "bob",

 "content": "This is a new post"

},{

 "id": 1001,

 "reply_to": 2000,

 "user": "bob",

 "content": "Replying to your post"

},{

 "id": 2000,

 "reply_to": 0,

 "user": "jane",

 "content": "This is my first post"

}

],

"more": false

}

4. 过程分析

下面具体分析一下这个一键生成环境的过程中都发生了什么

在任何一个github项目的地址前，加上https://gitpod.io/# ，就可以在gitpod中打开该项目，例如在eosforce-web-ide这个项目中点击Gitpod按钮，实际访问的就是https://gitpod.io/#https://github.com/ylic/eosforce-web-ide 这个地址

打开Gitpod之后，Gitpod会根据项目中的 .gitpod.yml 文件来决定环境的初始化工作，该文件内容如下：

image: ylic/eosforce-web-ide:v0.1.0 # Gitpod会加载ylic/eosforce-web-ide:v0.1.0的docker镜像，该镜像里面会部署编译好的eosforce相关程序，以及其他一些需要使用到的文件

ports: # 配置环境中需要打开的端口

port: 3000

onOpen: ignore

port: 8000

onOpen: ignore

port: 8080

onOpen: ignore

port: 8888

onOpen: ignore

port: 9876

onOpen: ignore

... #此处省略了部分端口

tasks: # 初始化阶段的任务

before: cd webapp

init: yarn　　　　# yarn会根据package.json文件去下载相关依赖包

command: nginx -c $PWD/nginx.conf; npx webpack-dev-server # 启动nginx反向代理

before: cd /workspace/eosforce-web-ide

command: ./nodeoscmd # 启动nodeos

以上步骤结束后，一个完整的eosforce测试环境就运行起来了，然后IDE会加载当前项目，开发人员就可以通过浏览器开发调试智能合约了。

总结

通过以上步骤，很大的简化了编写和调试智能合约的难度，使得更多的开发者可以接触到这个优秀的区块链项目和智能合约。同时，有了这些web IDE的相关指导文档，越来越多的开源团队也可以发布自己基于Web IDE项目，来方便开发者更好的对开源社区作出贡献。

Github链接：https://github.com/ylic/eosforce-web-ide

eosforce

2019年11月5日，EOS原力创始人孤矢在杭州 B-LABS 联合创业空间参加数字经济时代下的区块链动能论坛主题活动。

本届论坛由B-LABS、OK集团和嘉楠耘智共同发起，并联合浙江省金融科技协会、杭州市区块链应用专委会、中国区块链产业促进联盟、浙江大学区块链协会和中信出版社一同举办，是“区块链赋能数字经济”大话题下的先导论坛

在论坛活动上，孤矢发表了《Libra，DCEP格局之争—从货币主权到数据主权的全面竞争》主题演讲。他表示，作为区块链开发团队，更愿意在争夺数据主权上发力，和传统企业积极沟通，大力拥抱产业，找到那些“非区块链不可”的应用。

主要内容为以下几点：

一、Libra大概率无法做成
二、数据主权之争
三、区块链技术标准之争
四、区块链应用初露锋芒
五、区块链是一个新的时代
六、结语

以下为孤矢演讲实录。

《Libra，DCEP格局之争—从货币主权到数据主权的全面竞争》

大家好！其实我们是一个社区开发团队，关于讲DCEP和Libra的事情，应该说是轮不到我们来讲，我大概稍微说说。

我的标题是《Libra，DCEP格局之争—从货币主权到数据主权的全面竞争》。说实话，货币主权这个事情，传统的社区在讲的时候，加密社区还是有一种理想主义，说我们自由主义的货币无国界的类型，但是我认为货币主权这个事情其实还是国家与国家之间的竞争。那么，我们作为区块链的开发团队，更在乎的是第二件事情，就是数据主权。

Libra大概率无法做成

Libra是Facebook做的，其实不用DCEP出来，我们区块链的从业者，作为开发团队或者作为公有链的开发团队，我们也认为它大概率做不出来，因为其实我们所讲的全面的区块链或者说WEB3的时代，是一个应用和数据分离的时代，也就是说，即使你用微信，你的用户数据其实是跑在你自己这儿的，就是微信是用不了你的社区关系去卖广告给你的，这是我们的理解。

所以，我们并不认为Libra在这件事情上有多少的优势。我们也大概看了一下DCEP，它底层用的不是区块链技术，但是符合区块链精神，你要一个字符串，那么我就给你，这些开发者就可以用起来。这里面有一个非常有意思的设定，叫做“不预设技术”，这是什么意思？就是你可以用互联网的技术，也可以用区块链的技术，数字人民币都可以用，下面商业机构的使用都可以。但是其实不预设，问题就来了，那么什么技术可以让你证明你是你呢？其实只有区块链。就是说互联网技术在自己证明是自己这块上是很难做到的。

怎么说？Libra有自己的一系列问题，它有很多是不符合监管要求的，碰到的监管问题就甩给了下面所谓的做事商或者承兑商，把反洗钱的事情推给了下面的部门。但是，DCEP是一个监管非常强的东西。

数据主权之争

我大概讲一下我们擅长的部分，就在于数据主权之争。

大家都知道，为什么区块链讲话以后，人工智能、云计算、大数据以后都没有区块链这么火，为什么它的高度要超过以往？是因为整个互联网在中国20年的发展，其实你想象BAT是什么样的公司？是海外上市的公司，用户的数据不在用户身上。

国内的中小企业为什么搞人工智能搞不起来，搞大数据搞不起来，为什么A股的公司在这里面全部装不进去，其实这种中心化的数据公司是越来越强的，你产生垄断以后，根本不可能有新的团队产生，比如说小的团队想围绕用户的需求做创新，这非常之难。我在此之前做的事情就是在阿里生态下做了一个跨境的供应链平台，但其实很无趣，因为我是要跟着阿里去做的，这是以往的商业模式。所以，我当时从行业离开，跳到区块链，就是因为我觉得实际上玩法不应该是这样的，因此就跳到了区块链行业。

大家知道，今天讲消费互联网其实已经差不多成定局了，就是BAT对一个新的公司，行业里新的竞争对手来说，它的打击已经不是以前的纯粹海量打击。比如说拼多多，它已经很努力，但是阿里把整个物流体系买了以后，拼多多的物流成本是降不下来，所以不可能和大平台竞争。

区块链有一个什么好处呢？即使这个行业有一个区块链，数据其实是归属它的用户的，实际上没有人可以拿着用户的数据去和别人谈判。

比如说很典型的，之前的顺丰和阿里的争议，实际上双方都认为用户的数据是自己的，但我觉得其实在我们比较理想化里，我们会认为在未来，你的数据和你所使用的应用是分离的，今天如果你觉得微信不好用，删掉就可以了，可以用B信或者C信，你依然可以和微信好友沟通，这是一个非常理想的情况。而且好在刚才也讲到说可以在各行各业用，所以大家的热情会比较高。

因此，我认为很多区块链从业者或者说传统的互联网从业者，如果你把它简单地理解为一个风口，那么你会错过下一个20年，因为它绝不是这么简单。

最终，它做到的一个终极事情就是组织效率的竞争，狭义的区块链，单纯从区块链上来讲，它就是一个安全的数字结构，你可以理解为“区块+链”。

一份合同里每一页就是区块，链就是那个骑缝章。在广义的区块链里，把它上升为共识机制等等，这些是从哪里出来的？不是从区块链里出来的，是从比特币里出来的，你会发现纯粹的一个区块链就是一个数据结构。所以说，我们对于这个事情的理解，是说我们关注什么事情？我们关注以前在公有链的开发环境下，所有的数据是公开的，但是其实具体在一个产业的运用里，包括以前互联网公司进不到产业里的原因是，它还是在消费领域这样的打法，说我有一个云，你们把数据上传上去，无论他和传统企业怎么去有，但是它没有信用。不过为什么现在大家讲区块链愿意做呢？因为区块链有信用。

区块链技术标准之争

我再讲一个比较实际的东西，就是区块链的技术标准之争。当然，在联盟链的情况下会有很多。那么，技术标准之争具体在哪些方面呢？

第一，虚拟机。它就是一个智能合约运行的环境，说实话，这个竞争国内是相对落后的。大家知道在公有链里，其实第三方的开发者是非常多的，大家以前所使用的虚拟机是以太坊的EVM，但是它是非常老旧，不是针对区块链设计的虚拟机。

但是出现了另外一家公司，它的重心就是在做虚拟机，是专门针对于区块链设计的虚拟机。大家知道很多技术标准并不是说由谁制定的或者说补贴出来的一个生态，只是说这套技术非常好，开发者非常愿意用，围绕它的开发工具非常多，它才会成为一个技术标准，所以这是我们看到的第一个技术标准，就是虚拟机。

第二，账本结构。如果你把区块链单纯理解为一个账本的话，那么账本结构由谁定呢？我们看到有一个团队在做这件事情。

第三，跨链机制。A联盟和B联盟之间需要怎样的机制，这也是要研究的标准。

无论你用Libra也好，用阿里的也好，所有的开发者都回归不了以上的这些问题，就是主流的技术标准是如何定出来的。

我们是国内少数成建制的团队在开发公有链，以前中国人参与比特币和以太坊的开发都是一个人，甚至在以前公有链的开发团队里，都是个人开发者的协作。但是我们认为中心化在任务分配效率上来说更高，所以我们是第一个成建制的在做开发公有链。

区块链应用初露锋芒

区块链技术在一些行业中已经得到了应用。

第一，医疗数据与应用隔离。原先的区块链技术像水，水趋向于往无监管的方向走，但是它一旦落地，就非常难。因此，大家会往原生的区块链应用走，但是你会看到大量的问题，会给公众带来不好的印象，说区块链是不是只能做这些事情。

包括在习大大讲话之前，其实在加密经济领域，大家觉得它是一个典型的熊市下行的阶段，其实我们和无论是杭州还是世界各地的区块链开发者都沟通过，第一，公有链上的应用是非常之少的，都是围绕着投机、黄赌毒来的。但是在联盟链上的应用，实际上很多团队和银行或者和有title的单位合作的开发都是不赚钱的，甚至是趋于免费的。

所以说，它为什么给你做了这个东西，你不给钱？因为在以前，由于区块链的公众印象没有那么好，因为它是一个非常底层的技术，所以很多人无法理解，因此他认为区块链和数字货币、虚拟货币是一起的，我不用你，我觉得你就是没有信用。如果这样做的话，你做给我看，但是我也不给你钱。

甚至大类的，比如说在公有链金融、医疗领域，谁都可以设想一个很简单的答案告诉他这个行业应该是这样做，但是其实当你真正深入到产业里去的时候，产业也在发生变化。比如说，经过过去20年互联网的重组，比如说整个生产环节从原来以产定销到后面以销定产这些事情都重塑过了，所以如果按照以前的经验去做这个事情就非常难。

我刚才讲了，医疗数据与美妆供应链这两个事情是我从业这么多年来，我见到有人真实愿意付费去买的服务。

这是我大概上周的时候，我和我社区的人在聊，他在做什么事情呢？以前互联网公司跑到医院说要做大数据平台，你把你的数据放上来，我给你做大数据分析，没有一个医院愿意，因为国家法律规定医院的数据不能往外传。

但是他做了一件什么事情？我提供一个有隐私的数据环境，你的数据放上来，我的程序放上来，我给你一个结果，你的数据我就没有碰过，我可以证明我没有碰过你的数据。这对于从一线医院把宝贵的医疗资源向十八线的医院去投放有效医疗资源的时候，这是非常有效的，所以这是我第一个见到的愿意为区块链付费的，而且说实话，这非区块链不可，我们非常愿意找到这样的应用—非区块链不可。我们自己原生的区块链开发团队，我们擅长的部分都是提供底层的这些东西。

第二，美妆供应链溯源。以前的溯源其实都是假溯源，中间你贴了一个码，人家把码撕掉，贴上自己的码，然后假货也变成真货了。

第三，EOSC链上预算系统，其实就是原生的区块链应用。区块链上的激励机制都给了持币的用户或者挖矿的用户，但是我要钱怎么办？我们做了一个链上的预算系统，区块奖励大概有30%会进到预算系统里去，大家都能够看到，这个预算系统是由这个节点选择出来的一些委员会来负责的，就是说大家都可以向预算系统申请，整个过程是公开透明上链的。所以说，围绕着这个系统，我们团队在社区里的重要性在急剧下降，因为别的团队也可以来做这个事情。

以上三个应用，一个是原生的，就是链上治理的东西，另外两个真的是这么多年愿意付费来让你解决问题的区块链应用。

区块链是一个新的时代

我重新说一下刚才说的问题，区块链绝对不是一个简单的风口，或者说从互联网到移动互联网的转换，它是一个新的时代。

从生产关系上来讲，它会极致重构到什么程度呢？就像原子和原子的关系一样，它会把生产效率或者协作关系推向一个非常极致的地步。

第二，以往我们看到BAT垄断下、数据垄断下的问题，导致中小企业无法创新，它在体系内不停提高它的税收比例。那么，未来会出现一个数据与应用分离的超级大数据社会，就是说大家的数据可以打通，但是数据拥有权归你。以往任何一个靠流量的路径依赖，又靠用户数据生存的企业来说，它会很艰难。

第三，全新的可编程经济。以前加密货币里，无论是比特币还是说美元发行的USPD，它们的信用是没有那么足的，但是DCEP的信用非常足，由央行担保，所以波动性没有那么高。可编程是什么意思？如果你认为是一个账目，那么日常生活中用到签字、盖章的地方都需要区块链。

第四，监管前置的自由市场经济。以往对于统计局来说，它的统计数字是非常滞后的，监管是要跟着市场变化去走，但是无论是各地政府还是传统的可编程经济里，把这些大数据打通的话，对于监管来说，它确实可以从政务体系直接穿透到经济体系里去，所以它第一次实现了它对市场的敏锐感知会赶上甚至超过一般的小型公司，因为它对于政府的组织效率也是一种非常极致的重塑。

有个很有意思的事情，我们有一个核心开发者写代码非常厉害，他有一个困惑，说我们天天做这个玩意儿能够干什么呢？但是他后来为什么坚定的觉得这个行业不错，是因为有一次他去办社保，他说什么“最多跑一次”，我跑五六次都没有解决问题，如果政府把这套东西都用上的话，确实可以解决我一次都不用跑的问题。我看人民日报或者说习大大讲话，好像挺懂的，“最多跑一次”。

结语

以上是我今天大概要讲的内容，我希望大家：区块链作为一个非常底层的技术，不是每个人都可以理解的，比如说你今天用互联网，你不知道什么叫HTTPS。但是其实你要知道，它接下来带来的变革或者说这个工具有什么用，然后你再配合原有产业里的问题去解决。

我再说一遍，区块链开发团队在这场竞争里的优势其实没有那么明显，为什么？因为我只是发明了一个锤子，但是我根本不知道钉子要什么样的锤子，所以我们也是在拥抱产业，和传统企业去聊。你会发现，政府的人也理解的很快？因为一个数据库的底层，往上面走的话，你刚才讲的共识激励等一套东西，和你传统管理中用的东西差不多。所以我希望大家不要把它简单地当作一个风口去看，这是一个长跑，大家要去研究、使用它。

谢谢大家！

eosforce

本文来自EOSC社群分享活动第二期
作者：一枝独秀

大家都知道最近整个区块链行业在政策环境方面发生了非常大的变化，甚至是上升到了国家战略的高度。更重要的是，这一次对发过币的公链也予以了前所未有的肯定。

我认为这时候原力应该在不影响本身链的开发进度的情况下，主动拥抱党国，从一些公共事务入手，和政府合作。

举一个公共资源交易的例子，比如电子招投标中，电子招投标活动分为招标、投标、开标、评标、定标五个主要阶段，其中电子招标投标用户的身份确认、潜在投标人信息保密、评标委员会组成信息保密、投标文件防窃取与防篡改、开标环节的防解密失败、评委评标过程的防泄密和评标结果防篡改等是重点安全问题。

解决方案:

1.可以用区块链解决标书信息被盗取，被篡改，泄密的安全问题。
比如要求企业在确定封标后，标书加密，特征值上传到区块链，以上传时间为时间戳，建立存证区块。

2.可以利用加密技术对评标专家信息加密，随机筛选的行为及结果记录在链，通过分布存储，避免人为干涉的不公平现象。

3.可以用区块链技术使平台的操作行为可追溯等等。总之在公共资源交易数字化的过程中，肯定伴随着无数的交易安全问题，这都是可以用区块链解决的，原力可以尝试从这些落地方向提供技术服务去切入。

原力在落地主要有三个方面的优势

1.合规性优势，原力是国内公链少有的没有ICO融资和各种模式，在合法合规性上完全没有问题。

2．技术性优势，原力团队在过去这一年多的时间里已经证明了团队在开发实力方面毋庸置疑，其次原力链上有可定制化的一键启链功能，也可以一键启动联盟链，为政府部门低难度的提供技术服务开发不是问题。

3.地理优势，原力团队地处杭州市，杭州市政府在智慧城市，数字经济方面高度认可并且具备经验，依托杭州政府做一些公共事务领域的探索和尝试可能会形成示范效应。

我们看到原力这一年多里，不管是链本身的技术迭代，还是在社区治理方面都有明显的进步，但是在原力公链本身的知名度上还有所欠缺，原力的新闻在圈内往往也是不咸不淡。提高知名度的方法有很多，比如像最近EIDOS靠这种空投模式一炮而红，或者像孙老板疯狂蹭热度等等。

但是很明显这些都是原力已经所欠缺的，我认为原力提高知名度的办法不是去补短，而是要让长板足够长。原力是非常务实的技术团队，所以我们的重心就是要让技术更有效的落地。

除了政府公共事务，包括下面分享的原力企业联盟，如果能够形成技术服务的品牌效应，都会大大提高原力的知名度。当然，除了单纯的技术服务，如果能把这些并入到EOSC生态中，丰富EOSC应用场景就更好了，这需要更深入的研究，比如探索基于原力一键启链发行的其他链、联盟链与原力链交互，互相为彼此能带来什么。嗯差不多就是这些，哈哈希望原力上大家不要幻想，多集思广益，从务实出发，才能发展壮大。

Q＆A

问题:社群用户陈梅升-丰巢提问“感觉原力就是一面湖水静悄悄的”

回答：原力肯定不是静悄悄的，水面平静的背后是暗流涌动。具体做了什么，周四孤矢分享。

eosforce

北京时间2019年11月4日，EOSC 第一届预算管理委员会（EDBS-1）第四次会议成功召开，主要内容有：

一、预算管理系统官网版本已完成升级，新增「额度查看」功能、「提案撤销」功能；

二、与 DApp 团队接触交流，初步达成在 EOSC 上开发的意向；

三、讨论在预算系统中增加「悬赏」功能，方便社区用户申请提案，提升预算管理系统的使用性；

四、讨论是否成立 EOSC 宣传部，并将近期与秘书处及 BP 进行讨论。

「悬赏」功能的玩法暂定为任何人都可以向系统提交自己的创意，任务的底价 100 EOSC ，任务的奖金随时间的增加而增加。达到接单人认可的金额后，接单人接单。接单需要交纳任务奖金的 20% 作为抵押，如果在规定的时间内没有完成任何，押金没收，其它人可再次接单。每个任务，发起人可以领取总额 10% 的奖励。

eosforce

中文

开发进展

上周开发团队github 33 次提交。

完成EOSC Token Exchange合约, 配合社区开启测试.
完成EOSC Token Exchange 数据查询插件.
完善EOSC单元测试, 添加EOSC功能对应的测试用例.
整理EOSC文档, 添加新特性相关的文档.
完善EOSC初版子链方案技术文档, 设计跨共识证明机制.
搭建EOSC半节点框架, 对EOSC半节点进行性能测试.

社区动态

1.EOSC社区举办社群主题分享活动第一期，针对当前社群热点话题进行分享和讨论。

2.EOSC开发团队宣布竞选CoinEX主网节点，双方将在跨链技术、区块链虚拟机、隐私计算等方面深入合作。

EOSC英文社区举办万圣节活动，海外用户积极参与，反响热烈。

周报解读

本周，EOSC开发团队宣布将参与CoinEx主网节点竞选，在社区方面实现生态共同建设，在技术上也将进行多链跨链技术、区块链虚拟机、隐私计算等深入合作。

EOSC Token Exchange 已完成开发，并已在测试网上进行测试。EOSC Token Exchange合约是EOSC主网上进行交易撮合的合约，通过Token Exchange合约，用户可以实现链上交易，任何开发者/运营商都可以在支付内存费用的基础上创建链上交易对，交易费用由开发者/运营商收取。

下周工作

测试EOSC Token Exchange合约, 根据社区反馈进行优化.
完善EOSC单元测试, 添加EOSC功能对应的测试用例.
整理EOSC文档, 添加新特性相关的文档.
开发EOSC半节点框架: 完成Net插件框架, 实现初步的区块数据存储.
完善EOSC goeosforce库, 添加新特性支持.

English

Work Completed

The development team completed 33 submissions on Github.

Completed EOSC Token Exchange contract, coordinate with the community to start the test.
Completed EOSC Token Exchange data query plugin.
Improved support for EOSC unit test, added test cases corresponding to the EOSC function.
Collated EOSC document, added document related to new features.
Complete the technical document of EOSC’s first sub-chain plan, designed cross-consensus prove mechanism.
Built EOSC half-node framework, tested the performance of EOSC half-node.

Community News

The EOSC community held the first sharing event on the community themes to share and discuss current hot topics in the community.
The EOSC develop team announced to join the CoinEx Chain pre-election node process, and will conduct a series of in-depth cooperations with CoinEx in cross-chain technology, blockchain virtual machines and privacy computing.
The EOSC English community held a Halloween event, and the overseas users took an active part in it with huge enthusiasm.

Interpretation

This week, the EOSC development team announced that they will participate in the CoinEx main network node campaign, realize ecological co-construction in the community, and technically carry out in-depth cooperation on multi-chain cross-chain technology, blockchain virtual machine, and privacy computing.

The EOSC Token Exchange has been developed and tested on the test network. The EOSC Token Exchange contract is a contract for trading on the EOSC main network. Through the Token Exchange contract, users can implement chain transactions. Any developer/operator can create a chain transaction pair based on the payment of memory fees. Charged by the operator/operator.

Next week's plan

Test EOSC Token Exchange contract, optimize according to the feedback from the community.
Improve support for EOSC unit test, add test cases corresponding to the EOSC function.
Collate EOSC document, add document related to new features.
Develop EOSC half-node framework, complete Net plugin framework, and realize the preliminary block data storage.
Improve the EOSC goeosforce library, add new feature support.

eosforce

EOS CPU告急，主网再次拥堵

11月1日，ENU社区的创始人AP在EOS上发行了代币EIDOS（ENU Is Dead,Oh Shit），并再一次通过和ENU相同的代币分发方式对EOS社区进行空投。

根据EIDOS分发规则，EOS持有者可以发送任意金额到EIDOS的智能合约账户，智能合约会返回等量的EOS和账户池总量的0.01%的EIDOS。

这意味着，越早期参与的用户能够获得的EIDOS就越多。大量EOS用户涌入到了这场空投活动中，其火爆程度一点不输于当时的ENU。

然而，就在EOS用户争先想要效仿ENU的暴富神话时，号称百万TPS的EOS却率先崩溃，EOS社区内这场大规模空投活动直接导致了EOS全网拥堵。

截止到目前为止，EOS的CPU资源价格已提高了将近1000倍，转账一次需要抵押将近7000个EOS。同时主网CPU、NET等资源也一路暴涨，根据EOSpark数据光CPU这一项就上涨了109533.33%。这意味着，超过90%的EOS用户根本无法使用转账功能。

EOS的资源模型的利弊

这些问题是出于EOS的资源模型设置，在EOS中用户交易免费，但是必须要抵押足够的资源才能交易。

EOS将资源分为三类：RAM、CPU、NET，用户可以抵押EOS来换取资源的使用权。

RAM即内存，用来记录账户信息，包括账户余额、公钥、质押、投票、智能合约等。通常需要3KB-8KB的容量来存储个人EOS账户信息。RAM是可以随时买卖的，每笔收取0.5%的手续费，同时价格也是随RAM的稀缺程度时刻变动的。

CPU/NET是质押类型的资源。当EOS账户进行转账、投票等操作时，会消耗主网的算力和带宽，此时需要质押一部分EOS来换取CPU/NET，每天使用的算力和带宽会在24小时后重置。质押的EOS是可以随时赎回的，但是会存在72小时的冻结期。

这种解决方案不同于以太坊等直接收取GAS燃料费。EOS的方式使得交易费在资源充足的情况下，可以免费交易。这大大方便了开发者和使用者。但是因为节点的物理机器的计算能力和存储能力都是有限的，所以整个网络中用户能使用的资源也是有限的。

这次EIDOS代币空投事件，随着抵押EOS新用户数量的不断增加，价格也不断上涨，老用户原先拥有CPU的比例也会随之缩水，导致用户资源不足，无法交易。同时因为自由市场的缘故，会导致大量用户主动大量购买CPU，造成恶性循环。

EOSC资源模型的解决方案

EOSC主网是EOS原力团队在2018年6月基于优化后的EOSIO代码启动的主网，是EOSIO生态的一部分。

在EOS上线之初，EOS原力团队就曾经指出EOS资源抵押模型的弊端，恶意攻击者只需要抵押数万EOS就能低成本地让EOS全网陷入瘫痪。EOS原力为了使得所有用户都能使用到资源来进行交易，并解决主网运行中产生的一系列问题，对EOS进行了修改，建立了一套新的资源模型，在保证资源分配公平合理的情况下，尽量减少对于资源的滥用，让真正需要资源的用户可以使用EOSC网络提供的资源。

和EOS相比，主要有两点不同：

1）基于手续费分配的交易方式

在EOSC中，我们需要用户为其所触发的每一个action支付手续费，这一方式类似与以太坊CPU资源和NET资源是基于手续费分配。每一笔手续费会为其action提供一个CPU和NET的资源使用上限，对于系统原生的action如转账、创建用户、更新权限等action，可以采用固定手续费和限制的方式便于用户使用，在默认情况下，每次交易支付0.01 EOSC，这样又激励了开发者优化合约代码逻辑，提高资源使用率，又为用户带来了非常流畅的使用体验

执行过程：

cleost transfer eosforce test "5000.0000 EOS" "fo test"

executed transaction: ed62211eda722230472d416a8e3c92ab3f950fe951bcd357f9fb217792dac936 152 bytes 213 us

eosio <= eosio::onfee {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpb"}

eosio <= eosio::transfer {"from":"eosforce","to":"test","quantity":"5000.0000 EOS","memo":"fo test"}

eosforce <= eosio::transfer {"from":"eosforce","to":"test","quantity":"5000.0000 EOS","memo":"fo test"}

test <= eosio::transfer {"from":"eosforce","to":"test","quantity":"5000.0000 EOS","memo":"fo test"}

我们用eosforce账户给test账户转账了5000 EOSC，这个交易中只运行了 eosio::transfer action，所以对于这个action执行了对应的eosio::onfeeaction来向eosforce账户收取了 0.01 EOSC作为交易的手续费。

注意 eosio::transfer action会触发eosforce <= eosio::transfer和test <= eosio::transfer两个通知，但是这里两个账户都没用相应通知，所以这里只执行了一个action。

Eosforce会为transaction中的所有action分别计算手续费，这里的action也包括inline action，
如下面，这里testc是合约账户，当接受到转账时，会向另外两个账户testa和testb转账，这里构建一个transaction，向testc账户转账：

cleost transfer eosforce testc "5.0000 EOS" "fo test"
executed transaction: 6339c73f167602607c8ee1a89a73e7f0171f375b39b361eb47047f0e4a48c69d 152 bytes 646 us

eosio <= eosio::onfee {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpm"}

eosio <= eosio::transfer {"from":"eosforce","to":"testc","quantity":"5.0000 EOS","memo":"fo test"}

eosforce <= eosio::transfer {"from":"eosforce","to":"testc","quantity":"5.0000 EOS","memo":"fo test"}

testc <= eosio::transfer {"from":"eosforce","to":"testc","quantity":"5.0000 EOS","memo":"fo test"}

apply testc eosio transfer

eosio <= eosio::onfee {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpm"}

eosio <= eosio::transfer {"from":"testc","to":"testa","quantity":"5.0000 EOS","memo":"1;testa"}

testc <= eosio::transfer {"from":"testc","to":"testa","quantity":"5.0000 EOS","memo":"1;testa"}

apply testc eosio transfer

testa <= eosio::transfer {"from":"testc","to":"testa","quantity":"5.0000 EOS","memo":"1;testa"}

eosio <= eosio::onfee {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpm"}

eosio <= eosio::transfer {"from":"testc","to":"testb","quantity":"5.0000 EOS","memo":"1;testa"}

testc <= eosio::transfer {"from":"testc","to":"testb","quantity":"5.0000 EOS","memo":"1;testa"}

apply testc eosio transfer

testb <= eosio::transfer {"from":"testc","to":"testb","quantity":"5.0000 EOS","memo":"1;testa"}

warning: transaction executed locally, but may not be confirmed by the network yet ]

这个过程中，首先是eosforce向testc转账需要0.01 EOSC手续费，之后testc的合约触发了两个inline_action，分别是向testa和testb转账，这里由收取两次0.01 EOSC手续费，所以整个合约会收取0.03 EOSC手续费。既避免了宝贵有限的链上资源被无节制消耗，又使得每笔资源都相对独立不会影响到其他用户的使用体验和智能合约的正常运行，不会遭受“粉尘攻击”。

2）投票分红分配RAM资源

与CPU和NET不同，RAM采用租赁方式，以账户为单位根据其所缴纳租金来设置账户可以使用的RAM的上限，这里租金按照时间收取，为了方便用户操作，现阶段我们为每个账户设置了8kb的免租金额度，这样对于绝大多数普通用户是不需要关心RAM的，通常，开发者需要为其DApp所使用的RAM支付租金，包括了合约占据的RAM和执行中产生的RAM数据。

目前EOS原力实现了通过投票分红来支付租金的功能，在EOSC中用户投票可以获得分红，这形成了一个token流，而RAM租金也是按照时间和租赁的多少来计费，通过分红支付租金，一方面方便用户操作，不需用户经常补交租金和缴纳押金，另一方面可以提高投票率，促进链生态健康发展。

这个过程是这样的：

这种类似租云主机的方式以方式分配RAM资源, 用户可以通过使用投票分红来支付租赁RAM资源的费用, 这样即不需要用户担忧租金缴纳问题, 也杜绝了租金欠费的问题. 通过“以租代售”的方式, EOSC可以有效避免针对RAM资源的投机行为, 使得DAPP的发展不必受到RAM价格的干扰, 有效促进DAPP生态建设.

3）结语

这次事件我们可以看出，在EOS整个主网，EOS目前的状态远没有达到TPS交易上限，EOS的资源抵押模型导致EOS无法真正发挥出其出色的性能。这也通过事件证实了EOS的高TPS在区块链中的优势和应用。

BM在白皮书中表露资源模型的初心是---“降低开发者成本，让用户交易免费”。目前的资源模型还需要进一步的调整和修改。

EOS目前暴露出的问题在于其CPU资源模型, CPU实际上是一种时效性很强的资源, 在达到整个主网实际性能上限前所有限制用户的加成都是浪费资源, 同时EOS主网不应过分放任和迁就超级节点, 应该鼓励和敦促超级节点更新为良好计算设备, 在此同时开发工具和插件以减少同步节点对应的资源消耗, 所以可以通过以下思路改进：

增加一个指标衡量性能瓶颈，这个值应该和历史最高tps相关，并且设置一定的基于时间的增速来适应计算技术的发展, EOS主网已经奖励EOS给BP作为激励, BP不应提供过于落后的计算设备。
增加一个指标以衡量当前实际性能压力，这个指标应该和最近一段时间内的实际cpu消耗和用户抵押cpu总量正相关，链上可以动态调节这两者影响的比值, 这样兼顾性能实际消耗与未来消耗预期。
增加一个容量窗口加权指标，这个指标同当前性能压力成反比，和历史性能指标成正比，并定义一条以当前性能压力为参数的性能影响梯度曲线作为这个指标的加权值, 用这个指标作为用户cpu资源上限的加权值。
规划容量窗口指标的刷新机制, 这个机制应该间隔较短以减少用户拥堵预期。

当前EOSC，允许通过固定手续费和限制的方式来解决此问题。对于CPU和NET资源, 用户可以基于分红票龄支付手续费来达到类似EOSIO抵押获取CPU和NET资源的效果, 对于RAM, 用户可以通过抵押投票互换的形式来达到EOSIO基于市场购买的效果, 这样DAPP开发者也可以快速从其他EOSIO链切入EOSC, 并平滑的转向EOSC的资源模式。同时EOSC去中心化预算系统也近期上线，系统通胀发行的30％进入预算系统。在接下来会随着EOS一起共同发展和繁荣整个 dApp生态。

eosforce

Awake节点舍得、开发团队易sir、万币帮群主oneway于北京时间10月31日20:00在EOSC社群进行了演讲分享，分享的主题分别为：《10人的宣传组功能定义》、《预算案的基础费用+效果奖励解释》、《6人的宣传部详细分工》。

以下为EOSC社群主题分享活动第一期实录。

oneway《6人的宣传部详细分工》

EOSC 为什么要有宣传组？我的理解是 EOSC 实际上算是一个以社区为导向的「社区币」，目前主要参与方为 EOS 原力开发团队，超级节点 BP，秘书处，预算管理委员会。

EOS 原力开发团队负责主网代码的更新维护及其他功能的开发；超级节点 BP 负责出块，维护主网稳定，以及表决相关事宜；秘书处负责召集 BP 开会，收集社区意见，处理社区事务，链接社区与 BP ；预算管理委员会负责审批社区申请的预算，用于宣传推广或开发 EOSC 相关事项。

那么，EOSC 宣传组的加入刚好构成一个由 EOSC 开发团队、EOSC 超级节点、秘书处、社区、连通外界的一个闭环，EOSC 宣传组负责统筹处理社区人员的宣发需求，对外统一宣发，承担着向外界传递 EOSC 理念，宣传 EOSC 生态的作用。

如果设立宣传部，我的建议宣传组成员应该由负责媒体、社区、开发者、策略公关组成， 6 人即可。
渠道目前重点是国内：微信社群、币乎、微博、区块链垂直媒体、币 Coin 炒币社区等，此外如有能力覆盖海外推特、Facebook、电报群、海外媒体、国内科技财经媒体更好。

具体做法可以是，1、不断建立维护新的具有 EOSC 共识的微信群；2、不断撰写有关 EOSC 的文章；3、创建「EOSC 爱好者」微信公众号，发文章并入驻其他媒体平台；4、多发动微信群友转发 EOSC 相关文章或动态；5、有组织的传播、评论 EOSC；6、遇到任何热点，能够快速响应，并与 EOSC 相联系；7、朋友圈多转发 EOSC 相关动态等等。

社区问答

Q：我分享了宣传材料在我的朋友圈,有什么激励的措施给我呢?”

A：可由宣传组具体制定激励机制，向预算管理系统申请。

舍得《10人的宣传组功能定义》

EOSC社区成员，相比其它社区的成员，数量上少一些。但是我发现，我们EOSC社区的成员都很上心，没有那些CX的水军账号存在，成员的素质比其它社区要高太多了。EOSC社区的去中心化，完美了体现了区块链公平公开的精神，在这里我们可以集思广益，畅所欲言。但是从办事效率上讲，还是中心化公司的运作效率会更高，因为公司各个部门职责清楚，分工明确。

那我们是不是可以探讨去中心化社区与中心化公司的职能部门相结合的方式。刚才oneway已经分享了，目前EOSC社区主要有三个部门，BP，秘书处，预算系统委员会。我赞成组立我们社区的第四个部门，EOSC宣传部，人数在10人以内。宣传部的主要任务是组织，协调EOSC对内对外的宣传工作。包括区块链媒体，自媒体，渠道等方面的推广。

定期组织各种活动，扩大社区影响力，吸引新用户加入。宣传部人员，不一定要会写作，当然会写作更好了。只要有时间愿意为社区做事就可以。宣传部人员，可以每月可以向上系统领取一定的工资。其它外包兼职人员的相关奖励，也由宣传部代领，然后由宣传部统一发放。

宣传部设置部长一人，主持大局，其它人均为干事，协助宣传部长工作，定期选举替换。有了宣传部，社区就可以有一个统一的部署来推进宣传工作，比如，社区可以搞10个500人有群，当一篇人文章需要人去留言的时候，我们就可以在这10个群中发布消息，留言的可以获得一定的奖励。分分钟，留言就会被刷爆了。

社区问答

Q：有什么办法使这种分工比较去中心化呢？

A：这个分工，只是形式上的分工，实际上，对于成员来说，也还是去中心化的。公司的部门成员，基本上是不会轮换的。但是我们的社区部门不一样，会定期从社区中推举替换的。这就好比我们DPOS机制的节点一样。如果认为这种社区部门太过中心化，那基本上也可以认为我们的EOSC链上23个节点是中心化的。只有分工明确，工作效率才会提高。

易sir 《预算案的基础费用+效果奖励解释》

大家好我是易sir，目前是eosc团队技术运营。同时是Eosc社区委员会成员之一。今天我和大家聊的主题是关于去中心化预算系统的简单介绍。并介绍下目前的进展和结下来的规划。去中心化预算系统是由秘书处EOSFORCE主网改进提案 FIP #7提议中提出。为了更专业和高效的去中心化组织激励整个链的发展而建立的。在主网改进提案 FIP #7提议中第五条：建立去中心化预算系统—支持生态发展和第六条：设立《EOSFORCE主网管理委员会》机制—更专业和高效的去中心化组织激励整个链的发展详细介绍了去中心化预算系统和预算委员会。今天我给大家简单介绍下。

1、链上去中心化预算系统是什么
EOSForce Decentralized budgeting system（EDBS）是基于EOSC区块链平台拥有提案、投票和预算资金功能的去中心化系统。预算系统的代币由系统通胀发行的30％进入预算系统。在链上去中心化预算系统，任何人都可以发起申请预算提案。提案人发起提案需要抵押102个EOSC作为押金，防止垃圾提案，押金在提案通过后退回。提案人需要详细说明提案目标，实施细则（周期、成本、金额）以及提案将带来的回报。稍后我会详细讲解。

2、EOSFORCE主网管理委员会是什么
EosForce主网管理委员是为了促进去中心化预算系统更加合理公平的分配。由BP选举出专门负责管理EOSC去中心化预算系统 “EDBS”中提案、监督提案执行的人员。

管理委员会第一届人员由2019年10月11日EOSC主网第14届BP会议成功选举，第一届共有5个当选委员，分别是：eoswake舍得、jeepool大毛、汪伟、bepal怡宝、开发团队易传棋。

之后每半年增补2个人，最高不超过23人。目前我们预算委员每周周一开委员会议，这周是第三周，我们所有的会议内容都会上传至GitHub：https://github.com/eosforce/Dao/tree/master/EDBS，大家可以在这里了解所有信息。

3、如何进入去中心化预算系统
目前我们已经上线官网，大家可以直接通过EOSC官网，主页，进入预算系统。https://u.eosforce.cn/#/

大家如果是手机用户的话，也可以直接通过EOSC支持的钱包例如麦子钱包，AWAKE钱包，找到应用程序去中心化预算系统。

大家如果是手机进入的话，是直接登入的。可以直接使用，如果是电脑登入的话，需要安装scatter。我们已经将所有的教程放在预算系统的主页上，大家进入第一眼就能找到。方便大家了解和使用。

4、如何提案和查看
大家登入预算系统后，就可以直接点击我要申请提案，来发起自己的提案了。

提案的流程为4步骤：1、申请（提案人发起提案需要抵押102个EOSC作为押金，防止垃圾提案，押金在提案通过后退回） 2、审批 3、公示（提案获得管理委员会批准后，提案人在14天公示期之后可以发起提币提案） 4、执行

一般开发者发起一个提案需要填写详细资料息，为了给大家更加容易填写，已经将将完善的中英文版本的模版上传至GitHub，在发起提案页面大家就能看到查看模版。我们还将案例也添加在模版后面。

模版分为以下几块：
包括：项目名称、1、项目描述（开发目的、可满足需求、基本功能）2、项目功能（产品特点和具体功能点）3、项目链接（展示页链接）4、开发人员介绍（参与开发的角色、人数）5、开发周期（不同阶段的开发计划）6、开发费用（人力成本、服务器费用、维护费用等）7、申请token数量：合计开发费用。

当所有资料都填写完成后就可以直接提交申请了。所有申请的提案会由所有的提案都需要经过管理委员会大于2/3的同意方可生效。接下来你的提案就会显示在预算系统官网的主页上。

点击进去可以看详细内容，目前大家可以看到从预算系统上线到今天近三周的时间已经有3个提案。其中两个提案已经在公示期了，分别由 EosForce 团队开发的去中心化预算系统，和 Awake 团队开发的 EOSForce BP 管理平台 DAPP，还有一个第三方社区的宣传文章申请。

结下来这几天还会有一个在EOS2.0新上线的WEB IDE，然后还有一些社区的宣传已经dAPP陆续开始申请。也会有社区宣传的小伙伴在和我们聊申请。目前大家有任何好的想法，都可以和我们进行交流，内容不限于dapp、游戏、浏览器、文章、活动策划等等。我们目前当前待分配预算1918111.9787 EOSC。

大家如果有好的ider欢迎和我们交流。相信在接下来的时间里。EOSC主网会有越来越多的dapp和生态应用。

社区问答

Q：有类似KPI，的奖励方法参考一下吗？

A：会有类似kpi的，我们的代币发放是有两个流程，申请的之后提币需要重新申请提取数量。如果没有达到预期只能降低提取数量。这其实是一种类似kpi的形式。

Q：意思是说如果我们社区的人需要拉拢别的社区的人的话，就使劲的去申请预算就行了，实际实际得到多少预算，会有安排的？

A：对，早期是这样，我们会更具具体情况不断修正，不断改进。在效果最大化的同时并保证整个系统的公平。

Q：币东有什么权益和我为什要相信eosc好的公链？

A：原力团队为目前国内公链中唯一未进行过IC0或者任何代币募资团队，全部以自有资金支持技术开发，社区运营则由社区节点自发组织推进，为EOSC主网设计了完备的治理机制和预算系统，未来即使开发团队离开社区，社区也能通过自组织系统实现技术迭代和社区正常运转，同时EOS原力在EOS的系统上，做了大量优化和升级。

大规模Staking开创者：首创链上投票分红机制，开创staking模型，根据主网数据，链上用户投票比例最高达90%。掀起了行业staking热潮。

高度可定制化的区块链开发框架：开发出一套高度可定制的区块链开发框架，基于这套框架可以快速地启动一条区块链，可以基于中继跨链与其他链进行互操作。

时间加权的一票一投机制：主网上线之初便实行一票一投的投票机制，有效地防止节点联盟的出现，同时开发出基于时间加权的选举机制，参与投票的方式分为定期投票和活期投票。

首个POS链上去中心化预算系统：致力于去中心化运作，链上去中心化预算系统为社区贡献者、开发者提供预算支持，任何人都可以发起预算提案申请，并交由去中心化的预算管理委员会进行审批。实现区块链的长期可持续发展。

eosforce

导读

北美东部时间2008年10月31日14:10:00，中本聪在metzdowd.com上发布了比特币白皮书《比特币：一种点对点的电子现金系统》。随即，比特币在极客圈和密码朋克圈掀起了一股浪潮。

3年后，比特大陆创始人吴忌寒将比特币白皮书翻译成中文，并首次提出了”区块链“一词。此后，人们也用”区块链“来描述比特币的底层技术和设计思想。

受比特币的启发，加拿大开发者Vitalik Buterin于2013年首次提出以太坊的概念，并在2014年成功上线支持图灵完备的区块链平台以太坊。通过以太坊，开发者第一次实现了在区块链上发布智能合约的设想。但由于以太坊的性能并不理想，无法支撑起大规模分布式应用，区块链爱好者又翘首期盼一条交易速度更快的区块链。

2017年6月，美国工程师Dan Larimer发布了可实现高并发交易的区块链开源软件协议EOSIO白皮书，并在1年后正式发布EOSIO 1.0版本。EOSIO成功地解决了区块链性能不佳的历史问题，然而却由于治理机制的不理想为社区所诟病。

为了在高性能低延时与去中心化之间取得更好的平衡，EOS原力团队在2018年6月，基于EOSIO启动了EOSC主网，并在治理机制层面和技术层面做了大量改进和优化创新。

而到了今天，在国家政策的号召和支持下，区块链技术的应用和创新正在加速发展，越来越多人投入到了区块链的怀抱当中。要想深入理解区块链思想，更好地应用区块链技术，阅读比特币白皮书是必不可少的一步。

以下为比特币白皮书全文。

《比特币：一种点对点的电子现金系统》

作者：Satoshi Nakamoto
翻译：吴忌寒

[摘要]：本文提出了一种完全通过点对点技术实现的电子现金系统，它使得在线支付能够直接由一方发起并支付给另外一方，中间不需要通过任何的金融机构。虽然数字签名（Digital signatures）部分解决了这个问题，但是如果仍然需要第三方的支持才能防止双重支付（double-spending）的话，那么这种系统也就失去了存在的价值。我们(we)在此提出一种解决方案，使现金系统在点对点的环境下运行，并防止双重支付问题。该网络通过随机散列（hashing）对全部交易加上时间戳（timestamps），将它们合并入一个不断延伸的基于随机散列的工作量证明（proof-of-work）的链条作为交易记录，除非重新完成全部的工作量证明，形成的交易记录将不可更改。最长的链条不仅将作为被观察到的事件序列（sequence）的证明，而且被看做是来自CPU计算能力最大的池（pool）。只要大多数的CPU计算能力都没有打算合作起来对全网进行攻击，那么诚实的节点将会生成最长的、超过攻击者的链条。这个系统本身需要的基础设施非常少。信息尽最大努力在全网传播即可，节点(nodes)可以随时离开和重新加入网络，并将最长的工作量证明链条作为在该节点离线期间发生的交易的证明。

1. 简介

互联网上的贸易，几乎都需要借助金融机构作为可资信赖的第三方来处理电子支付信息。虽然这类系统在绝大多数情况下都运作良好，但是这类系统仍然内生性地受制于“基于信用的模式”(trust based model)的弱点。我们无法实现完全不可逆的交易，因为金融机构总是不可避免地会出面协调争端。而金融中介的存在，也会增加交易的成本，并且限制了实际可行的最小交易规模，也限制了日常的小额支付交易。并且潜在的损失还在于，很多商品和服务本身是无法退货的，如果缺乏不可逆的支付手段，互联网的贸易就大大受限。因为有潜在的退款的可能，就需要交易双方拥有信任。而商家也必须提防自己的客户，因此会向客户索取完全不必要的个人信息。而实际的商业行为中，一定比例的欺诈性客户也被认为是不可避免的，相关损失视作销售费用处理。而在使用物理现金的情况下，这些销售费用和支付问题上的不确定性却是可以避免的，因为此时没有第三方信用中介的存在。所以，我们非常需要这样一种电子支付系统，它基于密码学原理而不基于信用，使得任何达成一致的双方，能够直接进行支付，从而不需要第三方中介的参与。杜绝回滚(reverse)支付交易的可能，这就可以保护特定的卖家免于欺诈；而对于想要保护买家的人来说，在此环境下设立通常的第三方担保机制也可谓轻松加愉快。在这篇论文中，我们(we)将提出一种通过点对点分布式的时间戳服务器来生成依照时间前后排列并加以记录的电子交易证明，从而解决双重支付问题。只要诚实的节点所控制的计算能力的总和，大于有合作关系的(cooperating)攻击者的计算能力的总和，该系统就是安全的。

2. 交易(Transactions)

我们定义，一枚电子货币（an electronic coin）是这样的一串数字签名：每一位所有者通过对前一次交易和下一位拥有者的公钥(Public key) 签署一个随机散列的数字签名，并将这个签名附加在这枚电子货币的末尾，电子货币就发送给了下一位所有者。而收款人通过对签名进行检验，就能够验证该链条的所有者。

该过程的问题在于，收款人将难以检验，之前的某位所有者，是否对这枚电子货币进行了双重支付。通常的解决方案，就是引入信得过的第三方权威，或者类似于造币厂(mint)的机构，来对每一笔交易进行检验，以防止双重支付。在每一笔交易结束后，这枚电子货币就要被造币厂回收，而造币厂将发行一枚新的电子货币；而只有造币厂直接发行的电子货币，才算作有效，这样就能够防止双重支付。可是该解决方案的问题在于，整个货币系统的命运完全依赖于运作造币厂的公司，因为每一笔交易都要经过该造币厂的确认，而该造币厂就好比是一家银行。我们需要收款人有某种方法，能够确保之前的所有者没有对更早发生的交易实施签名。从逻辑上看，为了达到目的，实际上我们需要关注的只是于本交易之前发生的交易，而不需要关注这笔交易发生之后是否会有双重支付的尝试。为了确保某一次交易是不存在的，那么唯一的方法就是获悉之前发生过的所有交易。在造币厂模型里面，造币厂获悉所有的交易，并且决定了交易完成的先后顺序。如果想要在电子系统中排除第三方中介机构，那么交易信息就应当被公开宣布（publicly announced）[1] ，我们需要整个系统内的所有参与者，都有唯一公认的历史交易序列。收款人需要确保在交易期间绝大多数的节点都认同该交易是首次出现。

3. 时间戳服务器(Timestamp server)

本解决方案首先提出一个“时间戳服务器”。时间戳服务器通过对以区块(block)形式存在的一组数据实施随机散列而加上时间戳，并将该随机散列进行广播，就像在新闻或世界性新闻组网络（Usenet）的发帖一样[2][3][4][5] 。显然，该时间戳能够证实特定数据必然于某特定时间是的确存在的，因为只有在该时刻存在了才能获取相应的随机散列值。每个时间戳应当将前一个时间戳纳入其随机散列值中，每一个随后的时间戳都对之前的一个时间戳进行增强(reinforcing)，这样就形成了一个链条（Chain）。

4. 工作量证明（Proof-of-Work）

为了在点对点的基础上构建一组分散化的时间戳服务器，仅仅像报纸或世界性新闻网络组一样工作是不够的，我们还需要一个类似于亚当•柏克（Adam Back）提出的哈希现金（Hashcash）[6] 。在进行随机散列运算时，工作量证明机制引入了对某一个特定值的扫描工作，比方说SHA-256下，随机散列值以一个或多个0开始。那么随着0的数目的上升, 找到这个解所需要的工作量将呈指数增长，而对结果进行检验则仅需要一次随机散列运算。

我们在区块中补增一个随机数(Nonce)，这个随机数要使得该给定区块的随机散列值出现了所需的那么多个0。我们通过反复尝试来找到这个随机数，直到找到为止，这样我们就构建了一个工作量证明机制。只要该CPU耗费的工作量能够满足该工作量证明机制，那么除非重新完成相当的工作量，该区块的信息就不可更改。由于之后的区块是链接在该区块之后的，所以想要更改该区块中的信息，就还需要重新完成之后所有区块的全部工作量。

同时，该工作量证明机制还解决了在集体投票表决时，谁是大多数的问题。如果决定大多数的方式是基于IP地址的，一IP地址一票，那么如果有人拥有分配大量IP地址的权力，则该机制就被破坏了。而工作量证明机制的本质则是一CPU一票。“大多数”的决定表达为最长的链，因为最长的链包含了最大的工作量。如果大多数的CPU为诚实的节点控制，那么诚实的链条将以最快的速度延长，并超越其他的竞争链条。如果想要对业已出现的区块进行修改，攻击者必须重新完成该区块的工作量外加该区块之后所有区块的工作量，并最终赶上和超越诚实节点的工作量。我们将在后文证明，设想一个较慢的攻击者试图赶上随后的区块，那么其成功概率将呈指数化递减。另一个问题是，硬件的运算速度在高速增长，而节点参与网络的程度则会有所起伏。为了解决这个问题，工作量证明的难度(the proof-of-work difficulty)将采用移动平均目标的方法来确定，即令难度指向令每小时生成区块的速度为某一个预定的平均数。如果区块生成的速度过快，那么难度就会提高。

5. 网络

运行该网络的步骤如下：

新的交易向全网进行广播；
每一个节点都将收到的交易信息纳入一个区块中；
每个节点都尝试在自己的区块中找到一个具有足够难度的工作量证明；
当一个节点找到了一个工作量证明，它就向全网进行广播；
当且仅当包含在该区块中的所有交易都是有效的且之前未存在过的，其他节点才认同该区块的有效性；
其他节点表示他们接受该区块，而表示接受的方法，则是在跟随该区块的末尾，制造新的区块以延长该链条，而将被接受区块的随机散列值视为先于新区快的随机散列值。
节点始终都将最长的链条视为正确的链条，并持续工作和延长它。如果有两个节点同时广播不同版本的新区块，那么其他节点在接收到该区块的时间上将存在先后差别。当此情形，他们将在率先收到的区块基础上进行工作，但也会保留另外一个链条，以防后者变成最长的链条。该僵局（tie）的打破要等到下一个工作量证明被发现，而其中的一条链条被证实为是较长的一条，那么在另一条分支链条上工作的节点将转换阵营，开始在较长的链条上工作。所谓“新的交易要广播”，实际上不需要抵达全部的节点。只要交易信息能够抵达足够多的节点，那么他们将很快被整合进一个区块中。而区块的广播对被丢弃的信息是具有容错能力的。如果一个节点没有收到某特定区块，那么该节点将会发现自己缺失了某个区块，也就可以提出自己下载该区块的请求。

6. 激励

我们约定如此：每个区块的第一笔交易进行特殊化处理，该交易产生一枚由该区块创造者拥有的新的电子货币。这样就增加了节点支持该网络的激励，并在没有中央集权机构发行货币的情况下，提供了一种将电子货币分配到流通领域的一种方法。这种将一定数量新货币持续增添到货币系统中的方法，非常类似于耗费资源去挖掘金矿并将黄金注入到流通领域。此时，CPU的时间和电力消耗就是消耗的资源。另外一个激励的来源则是交易费（transaction fees）。如果某笔交易的输出值小于输入值，那么差额就是交易费，该交易费将被增加到该区块的激励中。只要既定数量的电子货币已经进入流通，那么激励机制就可以逐渐转换为完全依靠交易费，那么本货币系统就能够免于通货膨胀。激励系统也有助于鼓励节点保持诚实。如果有一个贪婪的攻击者能够调集比所有诚实节点加起来还要多的CPU计算力，那么他就面临一个选择：要么将其用于诚实工作产生新的电子货币，或者将其用于进行二次支付攻击。那么他就会发现，按照规则行事、诚实工作是更有利可图的。因为该等规则使得他能够拥有更多的电子货币，而不是破坏这个系统使得其自身财富的有效性受损。

7. 回收硬盘空间

如果最近的交易已经被纳入了足够多的区块之中，那么就可以丢弃该交易之前的数据，以回收硬盘空间。为了同时确保不损害区块的随机散列值，交易信息被随机散列时，被构建成一种Merkle树（Merkle tree）[7] 的形态，使得只有根(root)被纳入了区块的随机散列值。通过将该树（tree）的分支拔除（stubbing）的方法，老区块就能被压缩。而内部的随机散列值是不必保存的。

不含交易信息的区块头（Block header）大小仅有80字节。如果我们设定区块生成的速率为每10分钟一个，那么每一年产生的数据位4.2MB。（80 bytes * 6 * 24 * 365 = 4.2MB）。2008年，PC系统通常的内存容量为2GB，按照摩尔定律的预言，即使将全部的区块头存储于内存之中都不是问题。

8. 简化的支付确认（Simplified Payment Verification）

在不运行完整网络节点的情况下，也能够对支付进行检验。一个用户需要保留最长的工作量证明链条的区块头的拷贝，它可以不断向网络发起询问，直到它确信自己拥有最长的链条，并能够通过merkle的分支通向它被加上时间戳并纳入区块的那次交易。节点想要自行检验该交易的有效性原本是不可能的，但通过追溯到链条的某个位置，它就能看到某个节点曾经接受过它，并且于其后追加的区块也进一步证明全网曾经接受了它。

当此情形，只要诚实的节点控制了网络，检验机制就是可靠的。但是，当全网被一个计算力占优的攻击者攻击时，将变得较为脆弱。因为网络节点能够自行确认交易的有效性，只要攻击者能够持续地保持计算力优势，简化的机制会被攻击者焊接的（fabricated）交易欺骗。那么一个可行的策略就是，只要他们发现了一个无效的区块，就立刻发出警报，收到警报的用户将立刻开始下载被警告有问题的区块或交易的完整信息，以便对信息的不一致进行判定。对于日常会发生大量收付的商业机构，可能仍会希望运行他们自己的完整节点，以保持较大的独立完全性和检验的快速性。

9. 价值的组合与分割（Combining and Splitting Value）

虽然可以单个单个地对电子货币进行处理，但是对于每一枚电子货币单独发起一次交易将是一种笨拙的办法。为了使得价值易于组合与分割，交易被设计为可以纳入多个输入和输出。一般而言是某次价值较大的前次交易构成的单一输入，或者由某几个价值较小的前次交易共同构成的并行输入，但是输出最多只有两个：一个用于支付，另一个用于找零（如有）。需要指出的是，当一笔交易依赖于之前的多笔交易时，这些交易又各自依赖于多笔交易，但这并不存在任何问题。因为这个工作机制并不需要展开检验之前发生的所有交易历史。

10. 隐私（Privacy）

传统的造币厂模型为交易的参与者提供了一定程度的隐私保护，因为试图向可信任的第三方索取交易信息是严格受限的。但是如果将交易信息向全网进行广播，就意味着这样的方法失效了。但是隐私依然可以得到保护：将公钥保持为匿名。公众得知的信息仅仅是有某个人将一定数量的货币发所给了另外一个人，但是难以将该交易同特定的人联系在一起，也就是说，公众难以确信，这些人究竟是谁。这同股票交易所发布的信息是类似的，股票交易发生的时间、交易量是记录在案且可供查询的，但是交易双方的身份信息却不予透露。作为额外的预防措施，使用者可以让每次交易都生成一个新的地址，以确保这些交易不被追溯到一个共同的所有者。但是由于并行输入的存在，一定程度上的追溯还是不可避免的，因为并行输入表明这些货币都属于同一个所有者。此时的风险在于，如果某个人的某一个公钥被确认属于他，那么就可以追溯出此人的其它很多交易。

11. 计算

设想如下场景：一个攻击者试图比诚实节点产生链条更快地制造替代性区块链。即便它达到了这一目的，但是整个系统也并非就此完全受制于攻击者的独断意志了，比方说凭空创造价值，或者掠夺本不属于攻击者的货币。这是因为节点将不会接受无效的交易，而诚实的节点永远不会接受一个包含了无效信息的区块。一个攻击者能做的，最多是更改他自己的交易信息，并试图拿回他刚刚付给别人的钱。诚实链条和攻击者链条之间的竞赛，可以用二叉树随机漫步（Binomial Random Walk)来描述。成功事件定义为诚实链条延长了一个区块，使其领先性+1，而失败事件则是攻击者的链条被延长了一个区块，使得差距-1。攻击者成功填补某一既定差距的可能性，可以近似地看做赌徒破产问题（Gambler’s Ruin problem）。假定一个赌徒拥有无限的透支信用，然后开始进行潜在次数为无穷的赌博，试图填补上自己的亏空。那么我们可以计算他填补上亏空的概率，也就是该攻击者赶上诚实链条，如下所示[8] ：

假定p>q，那么攻击成功的概率就因为区块数的增长而呈现指数化下降。由于概率是攻击者的敌人，如果他不能幸运且快速地获得成功，那么他获得成功的机会随着时间的流逝就变得愈发渺茫。那么我们考虑一个收款人需要等待多长时间，才能足够确信付款人已经难以更改交易了。我们假设付款人是一个支付攻击者，希望让收款人在一段时间内相信他已经付过款了，然后立即将支付的款项重新支付给自己。虽然收款人届时会发现这一点，但为时已晚。收款人生成了新的一对密钥组合，然后只预留一个较短的时间将公钥发送给付款人。这将可以防止以下情况：付款人预先准备好一个区块链然后持续地对此区块进行运算，直到运气让他的区块链超越了诚实链条，方才立即执行支付。当此情形，只要交易一旦发出，攻击者就开始秘密地准备一条包含了该交易替代版本的平行链条。然后收款人将等待交易出现在首个区块中，然后在等到z个区块链接其后。此时，他仍然不能确切知道攻击者已经进展了多少个区块，但是假设诚实区块将耗费平均预期时间以产生一个区块，那么攻击者的潜在进展就是一个泊松分布，分布的期望值为：

当此情形，为了计算攻击者追赶上的概率，我们将攻击者取得进展区块数量的泊松分布的概率密度，乘以在该数量下攻击者依然能够追赶上的概率。
化为如下形式，避免对无限数列求和：

写为如下C语言代码：
#include double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } 对其进行运算，我们可以得到如下的概率结果，发现概率对z值呈指数下降。
当q=0.1时 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012
当q=0.3时 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006
求解令P<0.1%的z值：
为使P<0.001，则 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340

12.结论

我们在此提出了一种不需要信用中介的电子支付系统。我们首先讨论了通常的电子货币的电子签名原理，虽然这种系统为所有权提供了强有力的控制，但是不足以防止双重支付。为了解决这个问题，我们提出了一种采用工作量证明机制的点对点网络来记录交易的公开信息，只要诚实的节点能够控制绝大多数的CPU计算能力，就能使得攻击者事实上难以改变交易记录。该网络的强健之处在于它结构上的简洁性。节点之间的工作大部分是彼此独立的，只需要很少的协同。每个节点都不需要明确自己的身份，由于交易信息的流动路径并无任何要求，所以只需要尽其最大努力传播即可。节点可以随时离开网络，而想重新加入网络也非常容易，因为只需要补充接收离开期间的工作量证明链条即可。节点通过自己的CPU计算力进行投票，表决他们对有效区块的确认，他们不断延长有效的区块链来表达自己的确认，并拒绝在无效的区块之后延长区块以表示拒绝。本框架包含了一个P2P电子货币系统所需要的全部规则和激励措施。

1.W Dai（戴伟）,a scheme for a group of untraceable digital pseudonyms to pay each other with money and to enforce contracts amongst themselves without outside help（一种能够借助电子假名在群体内部相互支付并迫使个体遵守规则且不需要外界协助的电子现金机制）, “B-money”, http://www.weidai.com/bmoney.txt, 1998↵
2.H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements,"（在最小化信任的基础上设计一种时间戳服务器） In 20th Symposium on Information Theory in the Benelux, May 1999.↵
3.S. Haber, W.S. Stornetta, "How to time-stamp a digital document," （怎样为电子文件添加时间戳）In Journal of Cryptology, vol 3, No.2, pages 99-111, 1991.↵
4.D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping,"（提升电子时间戳的效率和可靠性） In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.↵
5.S. Haber, W.S. Stornetta, "Secure names for bit-strings,"（比特字串的安全命名） In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. on Computer and Communications Security, pages 28-35, April 1997.↵
6.A. Back, "Hashcash - a denial of service counter-measure,"（哈希现金——拒绝服务式攻击的克制方法）http://www.hashcash.org/papers/hashcash.pdf, 2002. ↵
7.R.C. Merkle, "Protocols for public key cryptosystems," （公钥密码系统的协议）In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980. S. Haber, W.S. Stornetta, "Secure names for bit-strings,"（比特字串安全命名） In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. on Computer and Communications Security, pages 28-35, April 1997. H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements,"（在最小化信任的条件下设计一种时间戳服务器） In 20th Symposium on Information Theory in the Benelux, May 1999. ↵
8.W. Feller, "An introduction to probability theory and its applications," （概率学理论与应用导论）1957 ↵

eosforce

管理委员会审批结果

同意/反对：4/0

项目名称

去中心化预算系统

项目描述

经过《 EOSFORCE主网改进提案V1.0FIP #7》会议内容，启动预算委员会来进行管理和组织生态应用开发。为此EOSFroce团队组织并开发了去中心化预算系统页面。目前已经开发完毕，并正式上线上线，同时在官方网页上添加入口，用户可以直接在官网跳转至预算系统网站。

项目功能

预算系统所有数据将在链上同步，所有人都可以通过scatter进行登入申请提案。目前已经拥有功能：
预选系统完整界面
通过scatter合约完整操作
申请版面设计
各个版面的设计，包括审批中、公示中、执行中、已完成四个阶段。
后续版本维护和更新。

项目网址

https://u.eosforce.cn/#/

开发周期

阶段1：产品需求（预计5个工作人日）
需求整理
原型设计

阶段2：UI设计（预计5个工作人日）
UI设计

阶段3：开发及上线（预计15个工作人日）
前端开发
后端数据对接
测试及上线

开发费用

工时：25个工作人日 500000 eosc
服务器费用一年：30000 eosc
维护费用一年：20000 eosc

总计：550000 eosc

eosforce

管理委员会审批结果

同意/反对：4/0

项目名称

EOSForce BP管理平台

项目描述

BP管理平台将集成BP的日常操作，提升BP相互协作的能力，向社区展示BP工作的进度。促进EOSC生态发展。

项目开发团队

团队名称： eosawake节点

社团队简介： eosawake社区是最早参与EOSC主网治理的节点之一，在EOSC生态上有开发Akdex去中心化交易所，Awake去中心化钱包。

团队联系：
https://t.me/eosawake,[email protected]

项目网址

https://api.akdex.io/bpmsig

项目需求

由于BP的日常工作需要用到BP账户私钥，现行的办法只能在命令行环境下进行操作，此种操作十分不便。BP管理平台可以解决这一需求，使BP日常操作无需电脑，可以随时随地在手机钱包上即可完成相关的操作。并且操作结果，全社区用户都可以查看。

项目目标

1)显示当前节点状态看板。

2)出块节点和备用节点相关数据显示，如出块数、票权、漏块数、罚金、押金、收益等。

3)各节点相关的操作，如漏块记录、增加押金、领取收益、提议惩罚节点、同意惩罚节点等。

4)节点多签模块，显示当前需要BP多签的列表，提供多签操作按扭。

5)节点信息填写和修改模块，方便节点使用bpinfo合约。

项目进度表

2019-10-01 立项
2019-10-02 项目需求分析
2019-10-05 项目架构设计
2019-10-08 项目开始编码
2019-10-12 内测
2019-10-15 公测
2019-10-20 正式上线

eosforce

中文

开发进展

上周开发团队github 30 次提交。

合并 EOSIO v1.8.5 更新到 EOSC.
完善 EOSC 单元测试, 完善新特性与EOSC链上配置支持.
完善 EOSC eosc_api_plugin, 整合EOSC特有的API, 整理.
完成EOSC初版子链方案技术文档, 开发轻节点demo, 测试同步性能.
开发EOSC Token Exchange合约.
调研 EOSIO Web IDE, 整理发布上手介绍文档.

社区动态

1.EOSC主网去中心化预算系统界面上线，首周收到两条提案并已通过审核。

2.开发团队申请参加Filecoin的测试主网启动验证活动。

3.EOSC英文社区成功举办社区推广活动，吸引数千位用户参与活动，社区人数翻倍。

运营团队与知名区块链信息平台CoinMarketCap(CMC)沟通对接，对EOSC在cmc排名进行更新。
阿拉伯地区知名区块链YOUTUBE视频博主对EOSC进行介绍推荐。

周报解读

本周，EOSC主网去中心化预算系统界面已正式上线，任何人都可以通过预算系统提交预算提案，为EOSC主网社区生态做出建设性贡献。

EOSC海外社区在本周发展迅猛，新增上千位社区用户，海外知名博主在YouTube上对EOSC进行介绍，帮助更多海外社区用户了解EOSC。

下周工作

配合社区更新EOSC主网.
完善EOSC单元测试, 添加EOSC功能对应的测试用例.
整理EOSC文档, 添加新特性相关的文档.
完善EOSC初版子链方案技术文档, 搭建EOSC半节点框架.
开发EOSC Token Exchange合约.

English

Work Completed

The development team completed 30 submissions on Github.

Merged the update of EOSIO v1.8.5 to EOSC.
Improved support for EOSC unit test, new features and support for EOSC on-chain config.
Improved eosc_api_plugin to integrate EOSC-specific API.
Completed the technical document of EOSC’s first sub-chain plan, developed light node demo, and tested synchronization performance.
Developed EOSC Token Exchange contract.
Investigated EOSIO Web IDE, collated and released the introduction document.

Community News

EOSC Mainnet Decentralized Budgeting System officially launched, two proposals were received and approved in the first week.
The development team applied to participate in the verification activity of the testing of Filecoin mainnet launch.
The English community successfully held a community promotion campaign, attracted thousands of users to participate in the campaign, and the number of the community members doubled.
The operation team communicated with CoinMarketCap (CMC), a well-known blockchain information platform, and updated the ranking of EOSC in CMC.
The famous blockchain Youtuber in the Arab region made an introduction video of EOSC.

Interpretation

This week, the EOSC main network decentralized budget system interface has been officially launched. Anyone can submit a budget proposal through the budget system to make a constructive contribution to the EOSC main network community ecology.

The EOSC overseas community has developed rapidly this week, adding thousands of community users. Overseas well-known bloggers introduced EOSC on YouTube to help more overseas community users understand EOSC.

Next week's plan

Coordinate with the community to update EOSC mainnet.
Improve support for EOSC unit test, add test cases corresponding to the EOSC function.
Collate EOSC document, add document related to new features.
Complete the technical document of EOSC’s first sub-chain plan, build EOSC half-node framework.
Develop EOSC Token Exchange contract.

한국어

작업 완료 됨

지난주 개발팀 github에 30 회 코드 제출이 있었습니다.

1, EOSC에 EOSIO v1.8.5 업데이트 병합

2, EOSC 단위 테스트 개선, 새 특성과 EOSC 체인 상 배치 지원 개선

3, EOSC eosc_api_plugin 개선, EOSC 특정 API 통합, 정리

4, EOSC 초기 버전 서브 체인 방안 기술 문서 완성, 라이트 노드 demo 개발, 동기화 성능 테스트

5, EOSC Token Exchange 컨트랙트 개발

6, EOSIO Web IDE 연구, 개시된 핸드북 소개 문서 정리

이번 주 커뮤니티 동태

1, EOSC 메인넷 탈중앙화 예산 시스템 인터페이스 출시되었고, 첫 주에 두 가지 제안이 제출되어 심사 통과되었습니다.

2, 개발팀이 Filecoin 테스트 메인넷에 참여해 검증 활동을 시작했습니다.

3, EOSC 영어 커뮤니티에서 커뮤니티 홍보 이벤트가 성공적으로 진행되었습니다. 수 천 명의 사용자가 이벤트에 참여해 커뮤니티 인원이 2배 증가했습니다.

4, 운영팀은 업계에서 가장 공신력 있는 CoinMarketCap(CMC)과의 소통을 통해 CMC에 등록되어 있는 EOSC의 랭킹 등의 정보를 업데이트했습니다.

5, 아랍 지역의 유명 블록체인 유튜버가 EOSC에 대해 소개하고 추천했습니다.

통역

이번 주 EOSC 메인 네트워크 분산 예산 시스템 인터페이스가 공식적으로 시작되었으며 누구나 예산 시스템을 통해 예산 제안서를 제출하여 EOSC 메인 네트워크 커뮤니티 생태에 건설적인 기여를 할 수 있습니다.

EOSC 해외 커뮤니티는 이번 주에 급속도로 발전하여 수천 명의 커뮤니티 사용자를 추가했으며 해외의 유명한 블로거가 YouTube에 EOSC를 도입하여 더 많은 해외 커뮤니티 사용자가 EOSC를 이해하도록 돕습니다.

l다음 주 계획

1, 커뮤니티와 협력해 EOSC 메인넷 업데이트

2, EOSC 단위 테스트 개선, EOSC 기능에 해당하는 테스트 사례 추가

3, EOSC 문서 정리, 새 특성 관련한 문서 추가

4, EOSC 초기 버전 서브 체인 방안 기술 문서 개선, EOSC 하프 노드 프레임워크 구축

5, EOSC Token Exchange 컨트랙트 개발

eosforce

本文为EOSC去中心化预算系统的使用教程，主要包含以下内容：

1.去中心化预算系统简介

2.安装和配置Scatter

3.提交预算提案

去中心化预算系统简介

EDBS简介：

EOSForce Decentralized budgeting system（EDBS）是基于EOSC区块链平台拥有提案、投票和预算资金功能的去中心化系统。

提案流程：

申请（提案人发起提案需要抵押大于100个EOSC作为押金，防止垃圾提案，押金在提案通过后退回）

审批

公示（提案获得管理委员会批准后，提案人在14天公示期之后可以发起提币提案）

执行

安装和配置Scatter

1.登陆EOSC去中心化预算系统 https://u.eosforce.io/#/，点击安装EOSForce定制版Scatter。

也可以直接登陆 https://url.cn/5nPo3Jk 进行下载。

2.根据电脑系统选择对应的版本进行下载EOSForce定制版Scatter。

windows系统下载.exe后缀文件

Mac系统下载.dmg后缀文件。

3.下载完成后，对Scatter进行配置。打开Scatter，选择 "I have my own private keys"
4.选择 "Accept Terms"

5.输入密码，用以解锁Scatter钱包。

6.选择导入私钥的方式，并完成私钥导入。

7.点击左边菜单栏中的”Networks“，接着打开右边EOSForce Mainnet 的开关，并关闭其他Network

8.回到Wallet，能看到已成功出现EOSForce账户。

提交预算提案

1.重新打开EOSC去中心化预算系统 https://u.eosforce.io/#/，网页会自动连接Scatter,选择账户和权限，点击Allow。若无反应可刷新页面或重启浏览器。

2.点击右下方“去抵押”按钮，抵押101个EOSC，在弹出的Scatter窗口中点击Allow。

3.抵押完成后，点击右下方“发起提案”。

4.根据管理委员会提供的去中心化预算系统开发费用申请模版，填写并提交提案。

详细申请模板参考地址：https://url.cn/5HKL2Ns

申请模板大纲：

一、提案标题：（填写项目名称）

二、提案简介：（使用Markdown编辑）

项目名称（与提案标题一致）

项目描述（开发目的、可满足需求、基本功能）

项目功能（产品特点和具体功能点）

项目链接（展示页链接，如无可空）

开发人员（参与开发的角色、人数）

开发周期（不同阶段的开发计划）

开发费用（人力成本、服务器费用、维护费用等）

三、申请token数量：合计开发费用。

四、更多细则：如有更详细的项目描述，可上传到https://github.com/eosforce/Dao/tree/master/EDBS后，填写文档链接，如无可空。

5.点击allow，成功提交预算提案申请。稍等区块确认后刷新页面，即可在“最新提案-审批中”查看到新提交的预算提案。

eosforce

麦子钱包支持中、英、韩三语版本，用户可以在麦子钱包上进行EOSC主网投票、转账、领取分红、账户创建等功能，还可以一键发行基于EOSC主网的Token、在EOSC主网上发布不可纂改协议等。

本文主要介绍如何麦子钱包的下载和使用。

下载钱包

1.使用浏览器登陆麦子钱包官网

http://www.mathwallet.org/cn/

2.麦子钱包有两种下载方式。（以IOS版本为例）

第一种是使用麦子钱包提供的海外Apple ID，到海外APP Store下载。

第二种方式是直接下载公测版，无需跳转到海外APP Store。以下教程以下载公测版为例。

3.选择安装公测版，点击“在APP Store中查看”，跳转到应用商店中安装TestFlight应用。

4.TestFlight安装完毕后，回到浏览器页面，点击开始测试，即可安装麦子钱包。

注：如果安装公测版麦子钱包失败，可以在确保钱包安全备份后，删除设备上已下载的麦子钱包，再重新安装测试版即可。

创建账户

1.点击钱包右上角，再点+号，点击创建钱包

2.创建钱包有两种方式。

第一种

点击右上方“如何获得邀请码”，点击页面给出的链接，通过支付宝支付购买邀请码。

第二种

点击下方的"让朋友帮忙创建EOS原力账户"，自己保管好生成的公私钥对，并把公钥和要注册的用户名发给已经有EOS原力账户的朋友，让朋友帮忙创建。

导入账户

1.导入账户前请先确保已经拥有EOSC账户

2.打开麦子钱包，选择钱包类型中滑到第二页，选择EOSForce。

3.按步骤导入私钥、密码，即可完成账户导入。

eosforce

中文

开发进展

上周开发团队github 29 次提交。

测试 EOSC v1.8.3版本.
完善 EOSC 单元测试框架支持, tester支持EOSC测试环境.
添加 EOSC eosc_api_plugin 以整合EOSC特有的API.
整理EOSC文档, 添加截止到 v1.8.3 的修改.
eosforce合约添加updateconfig功能，便于调整链参数.
设计EOSC子链架构方案, 整理EOSC异构跨链框架架构.
开发EOSC Token Exchange合约.

社区动态

1.社区节点发起关于调整节点漏块容错值和稳定值恢复时间讨论，调整参数已经在测试网进行测试。

2.韩国社区成功举行社区推广活动，社区人数增长30%。

周报解读

本周，社区节点针对节点漏块容错值和稳定恢复值时间展开讨论，并在测试网上对待选择的调整参数进行实际测试，以寻求一个在既能达到节点奖励的正向激励效果的同时，又能实现节点惩罚的反向激励目的的最佳数值。

下周工作

测试 EOSC 系统合约更新, 配合社区进行升级.
合并 EOSIO v1.8.5 更新到 EOSC.
整理EOSC文档, 添加新特性相关的文档.
完善 EOSC eosc_api_plugin, 整合EOSC特有的API.
完成EOSC子链架构方案文档, 开发跨链demo.
开发EOSC Token Exchange合约.

English

Work Completed

The development team completed 29 submissions on Github.

Tested EOSC v1.8.3.
Improved support for EOSC unit test framework, tester supported EOSC test environment.
Added eosc_api_plugin to integrate EOSC-specific API.
Collated EOSC document, add the modifications as of v1.8.3.
Added updateconfig function to EOSForce contract to facilitate adjustment of chain parameters.
Designed EOSC sub-chain architecture solution, organize EOSC heterogeneous cross-chain framework.
Developed EOSC Token Exchange contract.

Community News

Community nodes launched a discussion on the adjustment of block-missing fault tolerance value and the recovery time of stability value. The adjustment parameters have been tested on the test network.
The Korean community successfully held a community promotion campaign, and the number of the community increased by 30%.

Interpretation

This week, the community node discussed the node fault block fault tolerance value and the stable recovery value time, and actually tested the selected adjustment parameters on the test network to seek a positive incentive effect that can achieve the node reward. The best value for the purpose of reverse incentives that can achieve node penalty.

Next week's plan

Test the update of EOSC system contract, coordinate with the community for the upgrade.
Merge the update of EOSIO v1.8.5 to EOSC.
Collate EOSC document, add document related to new features.
Improve eosc_api_plugin to integrate EOSC-specific API.
Complete EOSC sub-chain architecture plan document, develop cross-chain demo.
Develop EOSC Token Exchange contract.

한국어

작업 완료 됨

지난주 개발팀 github에 29 회 코드 제출이 있었습니다.

1, EOSC v1.8.3 버전 테스트

2, tester의 EOSC 테스트 환경 지원을 위한 EOSC 단위 테스트 프레임워크 지원 개선

3, EOSC eosc_api_plugin 추가 및 EOSC 특정 API 통합

4, EOSC 문서 정리, v1.8.3의 변경사항 추가

5, 체인 매개변수 조정을 편리하게 하기 위해 eosforce 컨트랙트에 updateconfig 기능 추가

6, EOSC 서브 체인 아키텍처 방안 설계, EOSC 이기종 크로스체인 프레임워크 구조 정리

7, EOSC Token Exchange 컨트랙트 개발

이번 주 커뮤니티 동태

1, EOSC 시스템 컨트랙트 업데이트 테스트, 커뮤니티와 협력해 업그레이드 진행

2, EOSC에 EOSIO v1.8.5 업데이트 병합

3, EOSC 문서 정리, 새 기능과 관련된 문서 추가

4, EOSC eosc_api_plugin 개선, EOSC 특정 API 통합

5, EOSC 서브 체인 아키텍처 방안 문서 완성, 크로스 체인 demo 개발

6, EOSC Token Exchange 컨트랙트 개발

통역

이번 주에 커뮤니티 노드는 노드 결함 블록 내결함성 값과 안정적인 복구 값 시간을 논의하고 실제로 테스트 네트워크에서 선택된 조정 매개 변수를 테스트하여 노드 보상을 달성 할 수있는 긍정적 인센티브 효과를 찾았습니다. 노드 페널티를 달성 할 수있는 리버스 인센티브를위한 최고의 가치.

l다음 주 계획

1, 커뮤니티 노드에서 발의한 노드 블록 누락 허용 오차값 및 안정값 복구 시간 조정에 대한 토론 진행, 테스트넷에서 조정 매개 변수에 대한 테스트 진행

2, 한국 커뮤니티에서 커뮤니티 홍보 이벤트 진행, 커뮤니티 인원 30% 증가