设计目标

比特币作为区块链最成功的应用，它的功能仅限于加密货币的流通上。而作为将智能合约发展光大的以太坊，自发展以来遭到诸多非议，为了将自己打造成一个通用的区块链应用平台，其稳定性一直出现问题，社区的发展无法给应用的开发者更多的信心。我们的目标是构建一个特定应用领域的区块链平台，将商品流通信息与区块链标识绑定，利用区块链开放、不可篡改的特点来实现真正商品价值的流通，减少商品流通中各环节相互信任的成本。

生态系统

系统从逻辑上主要分为货币链与商品链两个部分，货币链提供平台上的加密货币功能，用于平台使用者向维护者付费，激励更多的节点加入到网络的运行中。商品链主要用来记录线下商品流通中的商品信息。

组件

系统从功能模块上主要分为以下几块：
区块，交易，共识算法，加密与哈希算法，p2p，SDK。

区块（Block）

区块保存了所有的交易，由于每个交易数据的大小不一致，区块一致性的维护、数据的同步需要考虑更多。同时，由于交易中保存较多的业务数据，数据索引的维护也需要在这个层次来做中。

交易（Transaction）

交易是在区块链操作的基本单元。区块链将沿用比特币系统的UTXO方法，（未交易输出，Uspent Transaction Output），在交易数据结构中需要加入一个特定字段来标识不同的数字资产，同时还需要一个类型字段来标识不同的交易类型，交易类型是记账人收费的依据。交易不仅需要发送者区块链账号的数字签名，同时也需要发送人的身份证书签名，以便在业务层次验证交易的有效性。

共识算法（Consensus）

类似与dBFT( 代理拜占庭算法)，商信链的股东通过投票选举1024个节点，在这些结点之间运行实用拜占庭共识算法，交易的费用平均分配给运行共识算法的结点，比较重要的是需要加入业务的逻辑来达到共识，区块产生的速度可以根据运营的策略进行修改，比如在晚上产生的区块速度更慢等。

加密与Hash算法

流通的数字货币使用椭圆曲线算法，同时由于一般交易包含的数据量较大，在构建Merkle树时计算的数据量也比较大，需要更高效的Hash算法。

p2p 协议

p2p协议负责交易的广播与接收，区块数据的同步等工作，相对于一般p2p广播的形式，在一个相对可信的环境下需要减少广播的数据量，因为每个交易都包含业务的数据会占用较多网络带宽。

SDK

应用程序开发接口，包括一个Restful调用接口和一个终端接口，前者用主要用于与应用的对接，后者用于区块链系统的调试。SDK功能包括交易的发送，用户账户查询，商品信息检索，网络信息等功能。

总结

为了完成上面这些组件的开发目前需要的技术包括不限于:
算法类：
椭圆曲线算法、dBFT、Swagger、mkdoc、DHT(分布式哈希表)、sha2、sha3、MerkleTree
工具类:
docker、ProtocolBuffer、levelDB