# High-Throughput Network
## Purpose
This network is used to understand how to properly design the chaincode data model when handling thousands of transactions per second which all
update the same asset in the ledger. A naive implementation would use a single key to represent the data for the asset, and the chaincode would
then attempt to update this key every time a transaction involving it comes in. However, when many transactions all come in at once, in the time
between when the transaction is simulated on the peer (i.e. read-set is created) and it's ready to be committed to the ledger, another transaction
may have already updated the same value. Thus, in the simple implementation, the read-set version will no longer match the version in the orderer,
and a large number of parallel transactions will fail. To solve this issue, the frequently updated value is instead stored as a series of deltas
which are aggregated when the value must be retrieved. In this way, no single row is frequently read and updated, but rather a collection of rows
is considered.
## Use Case
The primary use case for this chaincode data model design is for applications in which a particular asset has an associated amount that is
frequently added to or removed from. For example, with a bank or credit card account, money is either paid to or paid out of it, and the amount
of money in the account is the result of all of these additions and subtractions aggregated together. A typical person's bank account may not be
used frequently enough to require highly-parallel throughput, but an organizational account used to store the money collected from customers on an
e-commerce platform may very well receive a very high number of transactions from all over the world all at once. In fact, this use case is the only
use case for crypto currencies like Bitcoin: a user's unspent transaction output (UTXO) is the result of all transactions he or she has been a part of
since joining the blockchain. Other use cases that can employ this technique might be IOT sensors which frequently update their sensed value in the
cloud.
By adopting this method of storing data, an organization can optimize their chaincode to store and record transactions as quickly as possible and can
aggregate ledger records into one value at the time of their choosing without sacrificing transaction performance. Given the state-machine design of
Hyperledger Fabric, however, careful considerations need to be given to the data model design for the chaincode.
Let's look at some concrete use cases and how an organization might implement high-throughput storage. These cases will try and explore some of the
advantages and disadvantages of such a system, and how to overcome them.
#### Example 1 (IOT): Boxer Construction Analysts
Boxer Construction Analysts is an IOT company focused on enabling real-time monitoring of large, expensive assets (machinery) on commercial
construction projects. They've partnered with the only construction vehicle company in New York, Condor Machines Inc., to provide a reliable,
auditable, and replayable monitoring system on their machines. This allows Condor to monitor their machines and address problems as soon as
they occur while providing end-users with a transparent report on machine health, which helps keep the customers satisfied.
The vehicles are outfitted with many sensors each of which broadcasts updated values at frequencies ranging from several times a second to
several times a minute. Boxer initially sets up their chaincode so that the central machine computer pushes these values out to the blockchain
as soon as they're produced, and each sensor has its own row in the ledger which is updated when a new value comes in. While they find that
this works fine for the sensors which only update several times a minute, they run into some issues when updating the faster sensors. Often,
the blockchain skips several sensor readings before adding a new one, defeating the purpose of having a fast, always-on sensor. The issue they're
running into is that they're sending update transactions so fast that the version of the row is changed between the creation of a transaction's
read-set and committing that transaction to the ledger. The result is that while a transaction is in the process of being committed, all future
transactions are rejected until the commitment process is complete and a new, much later reading updates the ledger.
To address this issue, they adopt a high-throughput design for the chaincode data model instead. Each sensor has a key which identifies it within the
ledger, and the difference between the previous reading and the current reading is published as a transaction. For example, if a sensor is monitoring
engine temperature, rather than sending the following list: 220F, 223F, 233F, 227F, the sensor would send: +220, +3, +10, -6 (the sensor is assumed
to start a 0 on initialization). This solves the throughput problem, as the machine can post delta transactions as fast as it wants and they will all
eventually be committed to the ledger in the order they were received. Additionally, these transactions can be processed as they appear in the ledger
by a dashboard to provide live monitoring data. The only difference the engineers have to pay attention to in this case is to make sure the sensors can
send deltas from the previous reading, rather than fixed readings.
#### Example 2 (Balance Transfer): Robinson Credit Co.
Robinson Credit Co. provides credit and financial services to large businesses. As such, their accounts are large, complex, and accessed by many
people at once at any time of the day. They want to switch to blockchain, but are having trouble keeping up with the number of deposits and
withdrawals happening at once on the same account. Additionally, they need to ensure users never withdraw more money than is available
on an account, and transactions that do get rejected. The first problem is easy to solve, the second is more nuanced and requires a variety of
strategies to accommodate high-throughput storage model design.
To solve throughput, this new storage model is leveraged to allow every user performing transactions against the account to make that transaction in terms
of a delta. For example, global e-commerce company America Inc. must be able to accept thousands of transactions an hour in order to keep up with
their customer's demands. Rather than attempt to update a single row with the total amount of money in America Inc's account, Robinson Credit Co.
accepts each transaction as an additive delta to America Inc's account. At the end of the day, America Inc's accounting department can quickly
retrieve the total value in the account when the sums are aggregated.
However, what happens when American Inc. now wants to pay its suppliers out of the same account, or a different account also on the blockchain?
Robinson Credit Co. would like to be assured that America Inc.'s accounting department can't simply overdraw their account, which is difficult to
do while at the same enabling transactions to happen quickly, as deltas are added to the ledger without any sort of bounds checking on the final
aggregate value. There are a variety of solutions which can be used in combination to address this.
Solution 1 involves polling the aggregate value regularly. This happens separate from any delta transaction, and can be performed by a monitoring
service setup by Robinson themselves so that they can at least be guaranteed that if an overdraw does occur, they can detect it within a known
number of seconds and respond to it appropriately (e.g. by temporarily shutting off transactions on that account), all of which can be automated.
Furthermore, thanks to the decentralized nature of Fabric, this operation can be performed on a peer dedicated to this function that would not
slow down or impact the performance of peers processing customer transactions.
Solution 2 involves breaking up
没有合适的资源?快使用搜索试试~ 我知道了~
Hyperledger Fabric 源码 例子 依赖工具
4星 · 超过85%的资源 需积分: 25 34 下载量 39 浏览量
2017-11-01
11:03:05
上传
评论
收藏 22.95MB GZ 举报
温馨提示
共278个文件
pem:90个
crt:30个
sh:29个
Hyperledger Fabric 源码 例子 依赖工具 其中包含自动搭建开发环境脚本
资源推荐
资源详情
资源评论
收起资源包目录
Hyperledger Fabric 源码 例子 依赖工具 (278个子文件)
0d46ccf0e9436c1bc3b6e2bf80cdb202c4943604f95c72ee0ff839d3ec300719_sk 241B
0d9f72608133ee627b570b6af6877666bc8f365746f9329d6dd8a5f54e53e2ab_sk 241B
0e729224e8b3f31784c8a93c5b8ef6f4c1c91d9e6e577c45c33163609fe40011_sk 241B
1995b11d6573ed3be52fcd7a5fa477bc0f183e1f5f398c8281d0ce7c2c75a076_sk 241B
1deeab5433fa6e5f045eb763109d6165268fba153211af1281f00d45f54b1022_sk 241B
27ccb54a06020260c66c65bec91f91e1c9043e3076d3d6128692e7271c4c7a2c_sk 241B
27db82c96b1482480baa1c75f80e5cce249beaab27b70c741bb0e2554355957e_sk 241B
2fb065725bf1b7e2811c0e8ca8d37f5a951fc4cd1162a47aad8accf9ddd10291_sk 241B
4239aa0dcd76daeeb8ba0cda701851d14504d31aad1b2ddddbac6a57365e497c_sk 241B
46be1d569fe68f33e517c9e0072a0ccfbfb42727480fb8c8d0223af321a7893d_sk 241B
4d2f776c0fef8eac3f460a7c3558dc7859c4fe458e262e674a6c23f242ea33d1_sk 241B
585175c83bac91fc0c1ce8f9d0ff9aefa47c565678f100ca8673db249ee785ac_sk 241B
5890f0061619c06fb29dea8cb304edecc020fe63f41a6db109f1e227cc1cb2a8_sk 241B
6a211ed18880b4db3867831c977809902713b8e321a5ab55ecc104dafc2eec49_sk 241B
73cdc0072c7203f1ec512232c780fc84acc9752ef30ebc16be1f4666c02b614b_sk 241B
7bb8ba3ff11d3c8cf592bd4326062e77d06ac4963c7b7ae459284dfbd3eb5aac_sk 241B
8d2186556c85d515e737d0c0da8d0d7672785b685cb503bcb95e53dcc279fba7_sk 241B
945092d936f5838c5a6f6484db974d857933706737d00d04bf65f74e3976f9f8_sk 241B
a0606a4a860a1e31c90a23788da6f3b6b74925ed0d23061af4899409ba46ae6a_sk 241B
a7d47efa46a6ba07730c850fed2c1375df27360d7227f48cdc2f80e505678005_sk 241B
genesis.block 9KB
orderer.block 8KB
genesis.block 6KB
c75bd6911aca808941c3557ee7c97e90f3952e379497dc55eb903f31b50abc83_sk 241B
cd96d5260ad4757551ed4a5a991e62130f8008a0bf996e4e4b84cd097a747fec-priv 246B
cd96d5260ad4757551ed4a5a991e62130f8008a0bf996e4e4b84cd097a747fec-pub 786B
cd96d5260ad4757551ed4a5a991e62130f8008a0bf996e4e4b84cd097a747fec_sk 241B
config 276B
configtxgen 14.55MB
configtxlator 15.94MB
server.crt 912B
server.crt 912B
server.crt 908B
server.crt 908B
server.crt 891B
server.crt 875B
server.crt 875B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
ca.crt 855B
server.crt 834B
server.crt 834B
server.crt 834B
server.crt 834B
server.crt 834B
server.crt 834B
ca.crt 826B
ca.crt 826B
ca.crt 826B
ca.crt 826B
server.crt 814B
server.crt 814B
cryptogen 7.3MB
db670eed8487a93c35ae448b9f84c2f241a7a8c87df0544fc1dc08baf7832aa0_sk 241B
description 73B
ed3fd82393e95fc2c475afc113c8d2c591f745d1babc4d6d9cce0a1acc168acb_sk 241B
.env 25B
.env 25B
exclude 240B
fdee12a3510fde3155c37128cfec26090ae249bfbca28f884e60c21338493edd_sk 241B
.gitignore 520B
.gitkeep 0B
marbles_chaincode.go 24KB
high-throughput.go 16KB
fabcar.go 6KB
chaincode_example02.go 5KB
example_cc.go 5KB
chaincode_example02_test.go 3KB
sacc.go 3KB
HEAD 197B
HEAD 197B
HEAD 33B
HEAD 24B
pack-91d53fbf73f24a14c6434275700ec0d2111b74d9.idx 22KB
index 40KB
app.js 13KB
query.js 10KB
helper.js 9KB
instantiate-chaincode.js 6KB
invoke.js 6KB
invoke-transaction.js 5KB
join-channel.js 5KB
create-channel.js 3KB
install-chaincode.js 3KB
query.js 2KB
config.js 361B
network-config-aws.json 3KB
network-config.json 2KB
package.json 825B
package.json 507B
config.json 303B
server.key 241B
共 278 条
- 1
- 2
- 3
资源评论
- 工匠精神2018-01-13我下载了好多。也扣了好多C币
- 天气真好啊2018-04-02这个就是git上面源码,还要收费,过分啊
CodeCaptain
- 粉丝: 97
- 资源: 48
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功