读作FindGen，写作寻根。目的是对流通商品进行溯源。
还有一个含义，寻找下一代（Find Generation），找到未来商品流通方式和希望这个项目能抛砖引玉，做出更好的。
第一次做这种大型项目，有很多不成熟的地方，虽然没做到尽善尽美，但最核心的部分还是做出来了。
虽然区块链的原理都摆在那，但去理解和如何将我要解决的问题与区块链联系起来，实现溯源等问题，是难点，也正是我们要解决的。
完成这个项目，我的重点在设计，而不是在编写。
FindGen（以下简称FG）基于区块链体系来完成一个对商品进行溯源的系统。
FG由两部分区块链+GFW组成。
区块链涉及存储，加密，网络三个方面，很大程度参考比特币开发者文档。
GFW是为了解决一个具体问题（溯源问题），所设计的模型。之后有具体描述。
程序框架，分为三层，系统层，接口层，用户层。
虽然FG目前并没有表现出来，因为这是一个半成品。但在编写时，是按这个层次开发的。
简述开发流程，先完成系统层所需要的一些模块，只需简单的测试即可，然后在接口层，进行整合，根据我们要解决的问题，搭建模型。用户层，完成GUI（图形用户界面）。
第一次做大型项目，没有把握好节奏，直接将整个系统分配下去了，一开始的时候虽然有个大概计划，但没有很清楚的表示出来，导致前期开发很混乱，后期开始有条理进行开发了。
不过目前系统只有系统层与接口层，而且系统层缺少网络模块。接口层也没有很清晰的展示。
如需更详细的了解，见源码中的测试模块。
参考自比特币,大体相同
区块（Block）
Version : 区块链的版本
PrevBlockHash : 前一区块的Hash
MerkleRoot : Merkle树，根节点hash
Timestamp : 区块发布的时间戳
Nonce : 随机数，PoW共识算法的字段
Records : 包含多条流通记录
记录（Records）
version：标识记录版本（GFW版本）
sign：签名（由交易方签名）
pub_key：交易方的公钥crec：
goods_id ：商品ID（商品的唯一标识） seq ：流通索引
circulate_flag ：流通标识
time ：时间戳
recid ：记录标识符（hash）
adress : 被交易方的地址(base58)
区块统一使用此结构，记录虽然也是使用记录的结构，但是有两种模式的，一种是生产记录，由生产者（生产商）发布；另一种就是普通的商品流通记录。
生产记录，由生产者（生产商）一方填写。
普通流通记录，需要被交易方的参与。
具体如果填写，生成记录，见GFW处的描述。
区块链是整个系统的核心也是基础。
对于区块链，我认为区块链是个体系，虽然表现起来是条链。也有人说，区块链是个数据结构，我认为也有道理。
FG使用redis数据库与python的第三方库redis与redis进行通信。
redis是一个轻量级的数据库，一个实例占用不到1M。
存储在数据库是json字符。存储类型和在系统中的类型，一开始没有计划好，导致前期类型非常混乱，字节型，字符型，json型，python数据类型，最后统一使用字符型+json格式的字符和python数据类型。
目前系统层基本是字符型，接口层json格式的python数据类型。
下一阶段统一数据类型的处理，目前看来，整个系统对数据类型的处理没有很清晰。
FG加密部分有：公私钥+地址，签名，hash。
hash使用的是python内置库hashlib中sha256。
用到hash的地方有Merkel树，区块hash，交易hash，地址。
公私钥使用的是python第三方库fastecdsa的curve.P256。
地址采用，base58编码公钥的hash，base58_encode(版本+hash(pub_key)+校验和)。
签名，使用的是python第三方库fastecdsa的ecdsa（椭圆曲线数字签名算法）。
hash与签名需要注意需要hash和签名的数据和排序后再进行。
下一阶段，地址可以支持压缩存储（利用椭圆曲线的性质）。
注：仓库里虽然有AES，暂未实装，是之后会使用到的模块。
P2P网络，待构建。
GFW（商品来自哪里，goods from where）模型是为了利用区块链解决一个具体的问题所提出的，在FG系统里，是为了解决商品溯源问题。GFW位于接口层，底层（系统层）是区块链，GFW调用区块链，来解决商品流通溯源问题。
很多区块链应用，底层几乎差不多，如果想利用区块链解决其他问题，可以提出需要的模型。比如比特币的核心是交易，为了利用区块链解决交易问题，有UTXO（未花费的交易输出，unspent transaction outputs）模型。
接下来，具体看GFW模型。
在GFW中，商品有“生命周期”，用流通标识（circulate_flag）来标记各个“生命阶段”，基于这个提出流通规则，用来限制商品的流通的，保证“可信的商品”，GFW模型提出三条不能违背的规则。
基本规则
三条基本规则不能缺少，不能颠倒，不能更改，针对单个商品。
1.商品流通记录中必须有生产商签名。
2.商品流通记录中必须有生产商到销售商的记录
3.商品流通记录中必须有消费者购买商品的记录
基于基本规则，厂商也可以制定自己的流通规则。
之前说商品是有“生命周期”，所以商品是有结束的，在基本规则中，完成第三条的商品，“生命”结束。
利用这种方式，可以减少链上数据的流通，提高程序运行的效率。
因此，GFW中有URC（未完成的记录，unfinished record），类比于比特币的UTXO；区块链上所有未结束“生命”的商品，就是URC。
以上基本就是GFW模型的全部，还有一些内容待补充（模型中的参与者，更多名词在GFW的解释等），目前系统没有完全将这个模型实现。
系统中商品的唯一标识，使用雪花算法与ENA码来生成。
商品ID = 时间戳+商品编码（ENA码）+序列号
编码空间有浪费，有优化的空间。
流通标识（circulate_flag）：4字节
生产：0x000f
分销：0x00ff
消费者购买：0x0fff
商品生命结束：0xffff
0x0000-0x000f:上链|生产|准备
0x000f-0x0fff：分销|插件|中间流通
0x0fff-0xffff留作备用
此标识用于流通规则的编写。
由生产者（生产商）创建商品ID（现实世界物品上链），对记录签名，发布区块。
由交易方，选择属于自己的商品（地址，公钥验证，商品ID），对记录签名，广播记录，矿工“揽收”发布区块。
待构建。
包括两个方面：记录验证，区块验证。
记录验证：
- 签名验证
- 地址验证
- 流通规则验证（包括记录生成验证）
区块验证：
- 发布区块验证
- 接受区块验证
- 区块链验证
待构建
或者说矿工机制等。
- 为了方便安装，将程序打包docker（两种安装方式）并使用web访问的模式（B/S），目前使用CLI
- 实装GUI；目前暂未处理
- 多线程处理
- 共识算法的更新
- P2P网络模块
- ENA13商品ID生成，优化与添加验证模块
- 类结构调整；（Records类与Participants类；blockchain类与redis类等，方法权限管理）
- 验证模块统一；上链，发布区块，接收区块，发布记录，接受记录等
测试程序位于，仓库源码的测试模块。
