CarBlock服务于整个汽车及出行行业，是一个去中心化的区块链垂直平台，也是一个生态。互联网的本质是让信息流动起来，以数据作为入口来驱动汽车及出行行业基于数据来进行决策，并将所有业务高效的运转在CarBlock平台上，并吸引有创新能力的个人、团队、高校、研究所进入生态，最终进一步改变并提升整个汽车及出行行业。
CarBlock的发起有一个非常重要的时代背景：21世纪以来，“联网化”、“数据化”、“电子化”正在对汽车工业及周边行业带来颠覆性的变化。CarBlock由知名的车联网智能硬件公司 nonda (NO NDA inc) 孵化并最终独立运作，核心团队经历了 nonda 从初创到北美车联网智能硬件市场占有率第一的整个历程，亲身感受到变革大潮的来势汹涌，汽车及出行行业的所有传统观念都将被颠覆，无可避免。我们将在下一个章节详细分享我们在这方面的认知。
核心系统设计
1.系统架构
从系统架构来看，CarBlock系统整体架构分3层，共5个核心模块，如下图所示：
为了便于理解，我们可以将车联网的数据业务归纳为两个主要场景：数据采集与存储、数据交易。此外，由于车联网行业需求的特殊性，我们还需要构建一个CarBlock Chain 垂直行业链。因此，以下我们就将按照“CarBlock Chain 垂直行业链”、“数据采集与存储”、和“交易与智能合约”这三个小章节来详细介绍CarBlock系统的每个核心模块。
2.CarBlock Chain 垂直行业链
在核心系统架构图的右下角，就是CarBlock Chain 垂直行业链，包括虚拟机、账户、钱包等区块链核心模块。其实在系统设计初期，我们更倾向于直接采用以太坊（Ethereum）来实现相关功能，目的是尽量聚焦在核心业务上。但随着项目设计的深入，我们发现在这个场景下以太坊（Ethereum）有难以解决的缺陷，包括：
– 调用智能合约的Gas消耗
数据交易是CarBlock系统的核心场景之一，所有交易将由智能合约驱动（见“交易与智能合约”章节的讨论），确保交易过程透明、公平、可信任。但是以太坊的Gas消耗在这个场景下会存在阻碍性的问题，体现在：
1. GAS消耗费用太高；
2. 更要命的是，每次调用智能合约都会消耗GAS，不管智能合约的执行结果如何。举个例子，在你买房的时候，如果交易撮合失败也要收取你相同的费用，你会什么反应呢？
– 侧链（Sidechain）管理
侧链（Sidechain）是Blockstream团队首次提出的[10]，本质就是让交易只在少数节点参与的侧链上运行，只有最终结果才会合并到主链，最初的目的允许资产在比特币区块链和其它链之间互转，并降低核心的区块链上发生交易的次数。
侧链将是CarBlock系统的核心需求之一，因为和用于金融记账的比特币不同，绝大部分车联网应用场景只涉及个位数的参与者，并不需要通知整个网络，因此大部分智能合约可以在侧链上运行－利用侧链可以直接解决CarBlock系统潜在的拥堵问题。
但非常可惜，侧链在以太坊上至今尚停留在理论原型阶段，我们深深感到如果要依赖以太坊的侧链进展，将使CarBlock项目存在巨大的不确定性。
综上，为了解决和优化车联网的特定场景，我们必须推出CarBlock链。初期，CarBlock链将直接沿用以太坊的智能合约设计，基于Ethereum成熟代码先搭建测试网络，优先解决智能合约的Gas消耗、侧链（Sidechain）管理这两大问题，并根据车联网的行业特点进行优化。在基于Tendermint共识的Ethermint项目成熟之后，CarBlock链节点可以迁移到基于Ethermint项目的版本上。此外，Ethermint的优点是可以集成COSMOS-SDK开发，未来可以无缝接入COSMOS生态，进一步确保CAR Token可以跨链流通，实现我们对数据流通性最大化的追求。最后，构建在Tendermint上的CarBlock链，能满足交易对TPS的要求。迁移到Ethermint之后，共识采用基在Tendermint提出的POS方案，初始上线时，节点为2个，计划在上线后每年增加1-5个节点，直到最多100个节点。
3 数据采集与存储
数据采集的最底层是IoT硬件与传感器层，比如nonda公司的ZUS Smar t CarCharger可以提供车辆点火/熄火数据，电瓶电压数据，OBD可以将发动机相关的数据收集起来，TMPS监控轮胎气压与温度。传感器采集的原始信号会经过硬件加密，变成原始数据。加密后的数据通过蓝牙连接智能手机完成传送，或直接通过设备上的联网模块传送。不同维度的数据适用于不同的业务场景。
数据节点是储存车联网数据的核心。最底层的验证器（Validator）首先会校验来自硬件通讯数据的真实性。数据分两部分存储：
一部分是元数据（Metadata），仅包含所有用于查询的维度信息，以及指向它们对应的原始数据的索引，例如在IPFS上的哈希（Merkel Hash）。Metadata还将包含一些有效性验证数据，例如基于IPFS储存的数据将采用与Filecoin同样的“复制证明”技术，实现车联网原始数据存储及验证（存储有效性）。
另一部分是原始数据（Raw Data），包括两种形式：
1. CarBlock自身将利用IPFS协议，让包含Validator验证提取的所有信息储存在IPFS上。
IPFS的存储将采取3个方案：
– 由数据提供者来提供（默认方案）：由于不同数据所需要采样粒度和保存周期是不同的，我们的算法可以允许10GB以内的空间即可存储足够有价值的车联网数据，因此将数据直接存储在个人手机上是可行的，而且我们相信数据提供者也有足够动力来提供存储空间（细节将在下文探讨）。这个方案的好处是可以允许nonda大量的现有车主立即成为数据提供者来获取收益，无需更换设备，迅速实现项目“热启动”；
– 第三方（CarBlock基金会）在IPFS网络中提供存储服务节点：只要数据提供者愿意转让部分数据收益，他们可以采用第三方提供的存储服务节点。在初期，CarBlock基金会可以作为一个第三方存储提供者存在。
– 由设备来提供：CarBlock团队计划在未来发布新一代带存储的车联网设备，以实现更丰富和更强大的数据功能。
在IPFS协议之上，CarBock将采用Proxy Re-encr yption[19]来实现数据的加密和访问控制。在原始数据存储到IPFS的时候，将进一步分为2部分：对随机 秘钥K的加密串（EDEK）与加密数据文件，如下图所示：
当数据需求方希望访问并解密数据时，它需要先向数据提供者发起请求，数据提供者同意后向Proxy发送一个rekey。在这个场景下，还可以有一些第三方服务存在，比如验证数据需求方的身份、提供访问日志服务等，在这里就不进一步展开了：
接下来数据需求方将向Proxy发起请求，并获得一个rekey后的EDEK，再加上数据需求方的私钥，数据需求方就可以解密并访问原始数据。
利用Proxy Re-encryption，我们可以实现数据的一次加密＋多次授权，并且确保了：
– 一方面，只有指定被授权方使用自己的秘钥才能解密并访问原始数据；
– 另一方面，被授权方只能访问数据提供者的指定数据而并非全部数据；
而且幸运的是，在去中心化的世界中已经存在对Proxy Re-encryption的实现，即Nucypher KMS。CarBlock团队可以直接利用这样现有的服务，进一步节约开发资源和项目时间。
2. CarBlock同时也支持第三方车联网数据来源：通过利用ArcBlock[21]等跨链技术来实现跨链数据访问，我们允许第三方数据也在CarBlock生态中流动和变现，实现与更多的生态伙伴形成合作。事实上，CarBlock团队已经在前期工作中设计了跨链访问方案，但我们信任ArcBlock专业性，更倾向于分工协作，让我们资源更有效的倾注到车联网这个垂直领域。进一步来讲，如果在项目进行中出现ArcBlock的相关开发计划滞后于CarBlock需求的风险，我们将有两个备选方案：
– 投入资源参与ArcBlock相关开发，确保通过 ArcBlock协议可访问合作伙伴的数据；
– 或者，采用原设计方案来实现对特定合作伙伴的跨链访问；
总之，对于第三方车联网数据来源这块，CarBlock将采用一个通用的接口设计，让底层技术实现可以接近“插拔”（Plug & Play）的方式工作，实现松耦合。在元数据（Metadata）的上层是Privacy Mask，这是CarBlock专为车联网数据设计的隐私保护模块。
4.交易与智能合约
在数据交易场景中，数据交易所（Data Exchange）中数据交易将由智能合约来驱动，大致流程是：
1. 选择一个合适的智能合约设置模版（configuration template）；
2. 设置参数，如：购买哪些维度（sensor）的数据、scope（如所在地区、车型等）、数据量上／下限、报价、合约开始／结束时间、数据接收网关等；
3. 提交到数据交易所（Data Exchange）后会先进行一轮预处理，拒绝不合理的交易请求（如违反当地隐私保护相关法律的请求）；
4. 自动生成智能合约并开始运行；
5. 智能合约将根据维度和scope等参数来寻找合适的数据：
a. 如数据提供者已预定义授权规则（Authorization Rules），则根据规则自动决定是否参与；
b. 否则将发送请求到数据提供者，采用Request & Approval来进行决策；
6. 智能合约通过滤镜获得最终数据，将数据发送到指定的接收网关，并同时将Token（扣除一定手续Cost）发送到数据提供者的Wallet。
智能合约设置模版（configuration template）是数据交易所（Data Exchange）的核心，系统将由CarBlock团队及生态伙伴共同开发和维护。由于要保护车主隐私，车主个人信息（姓名、联系方式等）将不会发给数据使用者，因此涉及车主和数据使用者之间的商业逻辑必须在CarBlock链上发生。更复杂的使用场景可能会包括“报价”、“数字合同”等多种后续环节，例如：保险公司要为加州车主提供精确车险报价，则智能合约发送数据到接收网关后，还将等待并接受到保险公司计算出精确报价，然后发送到车主端。如果车主同意，则自动划拨保险金额的Token到保险公司，并证明双方完成数字合同。
由于智能合约是跑在CarBlock平台上的开源（Open Source）代码，可以从机制上（如“代码审核”等）确保商业逻辑安全、不会对双方的隐私或机密造成风险，因此我们认为未来必然将越来越受到公众的信任，从数据服务延伸到后续商业服务，随着更多生态伙伴的加入，让使用场景越来越复杂和多样化。
CarBlock经济模型
1.CAR Token发行
CAR Token 总量发行18亿个，永不增发，初始分配如下：
2.“挖矿”成本分析
如前文所述，CarBlock的数据提供者（车主们）提供大量有价值的出行数据，并获得CAR Token奖励，所以可以认为车主们在生态中扮演“矿工”，他／她们提供数据并获得Token的过程可以形象的称为“挖矿”。
“挖矿”的成本（价值）问题一直是一个有意思的话题，有些理论甚至认为挖矿成本就是Token价值的支撑点。CarBlock“挖矿”奖励算法在前文“挖矿”与贡献证明章节已经探讨，虽然我们并不完全认同“挖矿成本”和“Token价值”的关联性，但以下我们就将从“车主汽油消耗”的经济角度来粗略探讨一下CarBlock的“挖矿”成本：
– 从汽油消耗的角度，1CAR Token的“挖矿”成本 = (Driver数量 x 人均每日汽油消耗 x汽油价格)／每日Token发行量；
– 根据Motley Fool在2017年的报道，美国平均每个驾驶员2015年的汽油消耗是656加仑，即折合每天每人汽油消耗1.8加仑－我们假设这个用户驾驶习惯在数年内不会产生大的变化；
– 根据CNBC新闻报道，美国在2018年1月平均油价是$2.54－我们就取这个数字来作为汽油价格来参与计算；
– nonda将在其所有用户中推荐CarBlock，甚至将在其后续App中直接接入CarBlockSDK，提供车主数据获得奖励的“挖矿”功能。nonda在2017年的MAU是40万 ，所以CarBlock生态中Driver数量可以用100,000来作为一个非常可行的保底数字；
将以上变量代入公式可得：1CAR Token的“挖矿”成本 (USD) = (Driver数量 x 1.8x 2.54)／200000。根据100,000作为保底的Driver数量，我们可以绘制以下表格：
我们将募资价格来作为对比：
达到软顶的情况下，1CAR Token=0.00004ETH；
达到硬顶的情况下，1CAR Token=0.00011ETH；
诚然，以上的计算方式不尽完美，一方面驾驶者还要投入大量的时间，这可能比汽油更有价值；另一方面从驾驶者目的来看，他／她付出大量的油耗是因为行程的安排，而贡献数据并获得CAR Token只是顺势之举。所以以上计算只是说明了：如果存在“矿工”想以赚取CAR Token目的来进行驾驶，他／她将付出如何的最低成本，但我们不希望也不认为会存在这样的“矿工”，而且从计算结果来看，从驾驶来赚取CAR Token这个纯“挖矿”行为本身的成本不低。
3.CAR Token 使用场景
CAR（Utility Token）作为未来智能交通中最重要的角色，将在很多环节中发挥作用。为了便于描绘，我们将使用场景尽量合并，如下图所示：
关于更多CarBlock信息：https://carblock.io/