element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Internet of Things
  • Technologies
  • More
Internet of Things
Blog Blockchain - Hyperledger Burrow: set up a distributed ledger
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Internet of Things to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Jan Cumps
  • Date Created: 6 Mar 2020 10:48 AM Date Created
  • Views 2463 views
  • Likes 9 likes
  • Comments 7 comments
  • infineon
  • security_2go
  • blockchain
  • rt
Related
Recommended

Blockchain - Hyperledger Burrow: set up a distributed ledger

Jan Cumps
Jan Cumps
6 Mar 2020

This post is part of the Infineon Blockchain Starter Kit road test.

Blockchain - outside of the bitcoin context - is new to me.

Follow along with me on this path to learn the technology....

 

 

In the previous post, I set up a Hyperledger Fabric chain. In this post, it's going to be a small footprint Burrow chain. It's from the same organisation, but runs on small devices. Several chains can run comfortably on a Raspberry Pi.

image

I'm documenting the steps I used to get 3 chains running, synchronising and validating each other.

 

Prerequisite: have Burrow binary in your path. I've documented the raw steps in Road Test notepad: Infineon Blockchain Starter Kit.

Burrow uses the single binary executable approach. The same program is used to generate configurations, to generate keys, to run a ledger service, to run a synchronisation service, to deploy smart contracts, ....

 

We Will Set Up 3 Distributed BlockChain Ledgers and a Synchronisation Manager

 

A typical blockchain ledger landscape exists of a set of chains. Each participant can run their own local chain and have it synchronised with the others.

This will take care that there isn't a single source of truth, but a distributed one, validated by several parties.

 

In this Hyperledger Burrow example, 3 separate ledger instances are created. They all run a s a different process, a different entity. Writing to their own private database.

A 4th instance of Burrow has a complete different task. It's task is to let the 3 distributed instances talk, synchronise and validate each other. It's called a Seed instance in Burrow lingo.

There are other possible configurations. You don't need a Seed instance. You can register one ledger directly to another one. And ledger instances can double as Seed instance ...

 

image

 

The process is described in the Burrow Tutorial. I had to change a few settings though to make it work on my setup.

The configuration files I used are attached to this post (you can use them to copy/paste content), and I'll focus on the differences in this post.

 

On the Linux prompt, first create a play directory and navigate to there. I created ~/burrow_try.

 

Seed Node

 

Let Burrow generate seed keys and a configuration file template:

 

burrow spec --full-accounts=3 | burrow configure -s- > .burrow_init.toml
burrow spec -f1 | burrow configure --keys-dir=.keys_seed -s- > /dev/null
cp .burrow_init.toml .burrow_seed.toml 

 

Then make changes to the generated file burrow_seed.toml. I had to change the ListenAddress to 127.0.0.1 instead of 0.0.0.0 to make the whole process work.

If you know why, post in the comments.

 

BurrowDir = ".burrow_seed_0"

[Tendermint]
  Enabled = true
  SeedMode = true
  PersistentPeers = ""
  ListenHost = "127.0.0.1"
  ListenPort = "10000"
  ExternalAddress = ""
  AddrBookStrict = false
  Moniker = "seed_node_0"
  IdentifyPeers = false
  AuthorizedPeers = ""
  CreateEmptyBlocks = "5m"

[Execution]

[Keys]
  GRPCServiceEnabled = false
  AllowBadFilePermissions = true
  RemoteAddress = ""
  KeysDirectory = ".keys_seed"

[RPC]
  [RPC.Info]
    Enabled = true
    ListenHost = "127.0.0.1"
    ListenPort = "10001"
  [RPC.Profiler]
    Enabled = false
  [RPC.GRPC]
    Enabled = false
  [RPC.Metrics]
    Enabled = false
  [RPC.Web3]
    Enabled = false

 

You can now start the Seed node and retrieve it's address:

burrow start --address=`basename .keys_seed/data/* .json` --config=.burrow_seed.toml  > .burrow_seed.log 2>&1 &

 

When started:

SEED_URL=`curl -s 127.0.0.1:10001/network | jq -r '.result.ThisNode | [.ID, .ListenAddress] | join("@") | ascii_downcase'`
echo $SEED_URL

 

We'll use that address later to update our 3 chain configuration files.

 

3 Chain Nodes with Validators

 

Then, make 3 mor copies from the template file for the 3 chain instances:

cp .burrow_init.toml .burrow_val0.toml
cp .burrow_init.toml .burrow_val1.toml
cp .burrow_init.toml .burrow_val2.toml

 

Edit each of these files and make the following changes:

 

Chain 1:

 

BurrowDir = ".burrow_node0"

[Tendermint]
  Enabled = true
  Seeds = "PUT_HERE_SEED_NODE_ID@LISTEN_EXTERNAL_ADDRESS"
  SeedMode = false
  PersistentPeers = ""
  ListenHost = "127.0.0.1"
  ListenPort = "20000"
  ExternalAddress = ""
  AddrBookStrict = false
  Moniker = "val_node_0"
  IdentifyPeers = false
  AuthorizedPeers = ""
  CreateEmptyBlocks = "5m"

[Execution]

[Keys]
  GRPCServiceEnabled = false
  AllowBadFilePermissions = true
  RemoteAddress = ""
  KeysDirectory = ".keys"

[RPC]
  [RPC.Info]
    Enabled = true
    ListenHost = "127.0.0.1"
    ListenPort = "20001"
  [RPC.Profiler]
    Enabled = false
  [RPC.GRPC]
    Enabled = true
    ListenHost = "127.0.0.1"
    ListenPort = "20002"
  [RPC.Metrics]
    Enabled = false
  [RPC.Web3]
    Enabled = false

 

Chain 2, the same, except:

BurrowDir = ".burrow_node1"

[Tendermint]
  ListenPort = "30000"

[RPC]
  [RPC.Info]
    ListenPort = "30001"

  [RPC.GRPC]
    ListenPort = "30002"

 

Chain 3, also the same, except:

BurrowDir = ".burrow_node2"

[Tendermint]
  ListenPort = "40000"

[RPC]
  [RPC.Info]
    ListenPort = "40001"

  [RPC.GRPC]
    ListenPort = "40002"

 

You'll see that each node is the same, except that they all listen to different ports.

Again, the only changes are that in the [Tendermint] section, I had to change the ListenAddress to 127.0.0.1 instead of 0.0.0.0.

(If you don't like all this typing, grab the files from the attached archive and copy the relevant parts over).

 

Replace the Seeds placeholder with the Seed of the Seed node:

sed -i s%PUT_HERE_SEED_NODE_ID@LISTEN_EXTERNAL_ADDRESS%${SEED_URL}% .burrow_val0.toml
sed -i s%PUT_HERE_SEED_NODE_ID@LISTEN_EXTERNAL_ADDRESS%${SEED_URL}% .burrow_val1.toml
sed -i s%PUT_HERE_SEED_NODE_ID@LISTEN_EXTERNAL_ADDRESS%${SEED_URL}% .burrow_val2.toml

 

This will replace the fixed text that we typed in the Tendermint's Seeds attribute of all 3 config files with the Seeds node address we extracted after starting that node.

 

Then start the 3 chains:

burrow start -v=0 --config=.burrow_val0.toml  > .burrow_val0.log 2>&1 &
burrow start -v=1 --config=.burrow_val1.toml  > .burrow_val1.log 2>&1 &
burrow start -v=2 --config=.burrow_val2.toml  > .burrow_val2.log 2>&1 &

 

That's it. You can now check how many validators are running in each chain, and retrieve their IDs.

This again is different than in the tutorial.

In my case, Burrow doesn't use the values set in Moniker attribute but generates it's own unique ones:

 

pi@raspberrypi:~/burrow_try $ curl -s 127.0.0.1:10001/network | jq -r '.result.peers[].node_info'
{
  "protocol_version": {
    "p2p": 7,
    "block": 10,
    "app": 0
  },
  "id": "8d98af16e204ebec471f3405c2b02af433a7b50e",
  "listen_addr": "127.0.0.1:20000",
  "network": "BurrowChain_CC48E7-D0177C",
  "version": "0.32.8",
  "channels": "4020212223303800",
  "moniker": "BurrowChain_CC48E7-D0177C_Node_10831306A234166B3A4FA5AF20B340720B4A50C2",
  "other": {
    "tx_index": "off",
    "rpc_address": ""
  }
}
{
  "protocol_version": {
    "p2p": 7,
    "block": 10,
    "app": 0
  },
  "id": "5d2784a432f8ac1f942193f2240440814d967ece",
  "listen_addr": "127.0.0.1:30000",
  "network": "BurrowChain_CC48E7-D0177C",
  "version": "0.32.8",
  "channels": "4020212223303800",
  "moniker": "BurrowChain_CC48E7-D0177C_Node_058F785C636A31F61D9E7C73C5196F43D0CE8898",
  "other": {
    "tx_index": "off",
    "rpc_address": ""
  }
}
{
  "protocol_version": {
    "p2p": 7,
    "block": 10,
    "app": 0
  },
  "id": "8cf13f32943a1c3e8cd3a73967b6c78acc209907",
  "listen_addr": "127.0.0.1:40000",
  "network": "BurrowChain_CC48E7-D0177C",
  "version": "0.32.8",
  "channels": "4020212223303800",
  "moniker": "BurrowChain_CC48E7-D0177C_Node_1D03B0C6AB90644F96047D677E2D6E8149B2B55B",
  "other": {
    "tx_index": "off",
    "rpc_address": ""
  }
}

 

Here is a trace of a vote between the chains:

curl -s 127.0.0.1:20001/consensus

 

image

 

What now? First I want to find out why I had to make changes to the listener address. I could not find any evidence online that others had to do that.

Second, I'd like to run a few ledgers on different computers (PIs , BeagleBones, a VM on my laptop) and have them work together in a truly distributed setting.

And then, deploy smart contracts, post transactions, use the chains to create traceable events.

Ultimately, link in the Infineon Security 2Go smart cards into the process - either as ID to start the chain, or as signature mechanism when posting transactions ...

 

 

Related Blog
Blockchain - HyperLedger Fabric pt 1: post and search transactions on a distributed trusted ledger
Blockchain - Hyperledger Burrow: set up a distributed ledger
Blockchain - Get Some Crypto Currency on an Infineon Security 2Go Card
Blockchain - Debug the Infineon Demo App with Android Studio and Your Phone
Blockchain - Analyse the Infineon Android Demo App - part a: Detect Card
Blockchain - Analyse the Infineon Android Demo App - part b: Retrieve Ethereum Crypto Currency Balance
Blockchain - Analyse the Infineon Android Demo App - part c: Transaction, Move Crypto Currency to Another Account
Blockchain - Talk Directly to the Infineon 2Go Smart Cards API
Blockchain - Smart Contract Test
Road Test notepad: Infineon Blockchain Starter Kit
Infineon Blockchain Starter Kit - Review
Blockchain - HyperLedger Fabric pt 2: application using blockchain and smart contract
Blockchain - HyperLedger Fabric pt 3: web console
  • Sign in to reply

Top Comments

  • DAB
    DAB over 5 years ago +1
    Hi Jan, If I understand this correctly, the blockchain sw generates ID's and Keys for each user to establish sets of secured data using encryption and decryption. Each user is then protected from intruders…
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to DAB +1
    This image may explain it better, DAB You see that each block has it's own hash and the hash of the previous one. You'd have to manipulate all blocks after the one you try to tamper with, to get away with…
  • DAB
    DAB over 5 years ago in reply to Jan Cumps +1
    Thanks Jan, I had not thought of that aspect, but it now makes sense. DAB
  • Jan Cumps
    Jan Cumps over 3 years ago

    update: according to hyperledger, the Burrow project is now dormant.

    image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • DAB
    DAB over 5 years ago in reply to Jan Cumps

    Thanks Jan, I had not thought of that aspect, but it now makes sense.

     

    DAB

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to DAB

    This image may explain it better, DAB

     

    You see that each block has it's own hash and the hash of the previous one.

    You'd have to manipulate all blocks after the one you try to tamper with, to get away with it. And while doing that, you'd not get the votes from the other distributed partners to validate it...

    image

     

    source: Villem-Oskar Ossip --  Ethereum blockchain and HyperLedger Burrow blockchain comparative analysis -- Bachelor’s Thesis (9 EAP)

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago

    The same exercise - 3 chains and a Seed node -  on Ubunto 19 64-bit (VM on Windows10)

     

    image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to DAB

    It works different. The keys are used to calculate a hash based on the previous and the new transaction  value in the chain.

    And those chains get distributed to all players and validated. Once it’s shared, you can’t change any value in the chain without detection by the others.

     

    Focus here is on an immutable ledger of transactions. Once a transaction is recorded, it’s set in stone, hard to cheat.

     

    By default, these values aren’t hidden or encrypted.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube