Abstract

Voting is a fundamental right of citizens who live in a democracy. We at Blockchain Consulting were approached several times to evaluate voting systems. Despite the obvious advantages of using blockchain for voting, there are also some problems such as vote privacy. For years, people have been struggling to find workarounds for these downsides, and it still remains hard to find solutions. In 2021, we decided to develop our own voting application and to use it for in-house purposes. Our goal was to find solutions to some of the problems that could not be solved yet.

Voting on blockchain

Voting was already part of the attic democracy in 500 b.c. and, despite technological advancements , the voting process is pretty much the same today as it was back then. The voter receives the ballot, checks a box next to their preferred choice in private, upon which someone collects and counts everyone’s votes to determine the winner .

One of the first ideas for using  blockchain technology for something other than payment solutions and financial services was to use it for voting processes. People envisioned a faster and more efficient voting process. They also thought the immutability of a blockchain would guarantee trust in the result. Trust is an important component. Just take the 2020 US presidential election and the huge debate around postal votes. Even in modern democracies, the element of trust in a voting process is definitely a weak point.

Most famously, Ethereum founder Vitalik Buterin referred to a statistic which suggested that 27% of mail-in ballots were not counted in South Florida in the 2020 presidential election. He Thereby claimed it would not be that hard to beat an accuracy of 73% and supported the idea of voting on blockchain. (Mapperson, 2020)

Analysis of voting processes on blockchain

At Blockchain Consulting we researched possible blockchain-based voting processes throughout the years and closely followed the developments in this area. When the Republican party Utah GOP convention used a blockchain-based voting application in April 2020, we looked into the application they used and analysed the process once again. (Anzalone, 2020)

The general advantages of blockchain-based voting are:

• Real time confirmation of the votes
• Transparency, as all transactions are recorded on the blockchain
• Data integrity due to decentralized consensus mechanisms
• High level of security through decentralized infrastructure

Despite these advantages there are also problems that require  widely accepted solutions:

The first and most common  problem is privacy. It needs to be ensured that the person voting can only vote once – therefore, we need to know who is voting. How can the process remain anonymous if it has to be verified that one individual only casts one vote. 

The wide and imprecise answer to this problem is usually “cryptographic methods”. So far we have not yet found a method that ensures 100% privacy without trusting  a third party.

Idea creation

Here at Blockchain Consulting, we use a prototype approach to test concepts and processes, and to find further solutions to potential problems . Upon researching  how to ensure privacy on a public blockchain, the natural choice for a testing environment were the simple, non-critical everyday polls of our daily office lives. Nevertheless our goal was and still is to derive ideas and develop solutions based on the status of the application. We decided to develop a blockchain-based voting application for internal purposes, through which employees were able to democratically vote on questions regarding  

• Projects
• Workshops
• Lunch

Development phase

In our application, the voting process is a smart contract with variable attributes such as:

• Voter: Eligible users can be added to the voting.
• Ballot: A set of choices a voter is able to cast.
• Time: The time span during which valid votes can be taken into account. After this period the election will be closed.

The first step involved deciding on  a suitable blockchain on which  this sort of  voting system can be realized as a smart contract. We decided to go with the Ethereum testnet, as the Ethereum Blockchain is able to fulfill our needs, plus Blockchain Consulting already had experience with coding smart contracts on this blockchain (Cf. Report about Hashrate Token).

The voting application was developed on an Ethereum testnet called “Polygon”. Polygon is a framework for Ethereum-based smart contract developers. (Bhalla, n.d.) By using Polygon you are able to launch your own Blockchain, which has all the advantages of the Ethereum Blockchain, as it communicates with the legacy Blockchain by interoperability. Having your own Blockchain for a voting process has the big advantage of using a sandboxed environment. Additionally, you gain all the advantages of Ethereum. The user authentication will be done by metamask. Metamask is an application through a compatible web browser. It allows users to store and manage account keys and to process transactions on Ethereum based cryptocurrencies and tokens, which is important because smart contracts run on Ethereum.

The ballot is the atomic unit in this system and contains the following parameters:

• The name of the election
• A unique identifier
• End of the voting time frame
• One or more choices by the voter. The issuer decides how many votes can be cast.

The voting smart contract contains the following functions

• Vote: This function represents the voting process itself.
• Results: Shows the results of the election.
• addVoters: Voters can be added to the election with their wallet address 
• createBallot: Ballots will be created after all participants are in place.
• getBallot: See the anonymized results of a ballot

Fig. 1: Structure of the smart contract and its containing functions

Practical usage

This is clearly a very centralized voting application, which is acceptable because for now it is only used for in-house purposes. The polls are issued by our HR department. 

It works as described in the following:

The issuer decides the name of the election and its ending date.

The issuer then writes down the voting choices. Then the issuer decides who is allowed to vote in this particular election by adding their wallet addresses.

All eligible voters are now able to vote and write their choice into the smart contract. All these processes will be stored on the Blockchain and are therefore resistant to fraud.

Our developers designed a clear User interface, so the process looks more like a vote and not like a transaction.

Once the vote is over  or every voter has used the token provided, all votes are counted and it becomes clear which option is preferred and by how many.

Further developments

The voting application is still a prototype and under active development. It may seem simple and almost basic, but that’s certainly not the case. The application so far has strengthened our understanding of blockchain technology and allowed employees from all departments to use a smart contract, get accustomed to metamask and complete a transaction on the blockchain. As a company from the blockchain space it seemed just right to offer a voting system like this. 

Furthermore, our developers get to think more deeply about the problems of voting privacy, how to address them and find a solution that is secure and widely accepted. There is still a long way to go but the first steps have been taken and our goal is to finalize the first version for the market soon.

Bibliography

Anzalone, R. (2020, 04 29). Utah Republican Convention Uses Blockchain Voting Service. Utah Republican Convention Uses Blockchain Voting Service. https://www.forbes.com/sites/robertanzalone/2020/04/29/utah-republican-convention-uses-blockchain-voting-service/

Bhalla, A. (n.d.). What is Polygon MATIC? How does Polygon work? What is Polygon MATIC? How does Polygon work? https://www.blockchain-council.org/ethereum/what-is-polygon-matic-how-does-polygon-work/

Mapperson, J. (2020, 11 05). CZ and Vitalik agree blockchain-based voting is a must. CZ and Vitalik agree blockchain-based voting is a must. https://cointelegraph.com/news/cz-and-vitalik-agree-blockchain-based-voting-is-a-must

Abstract

The task at hand was to find a way to use Bitcoin in an everyday setting, in our own office. As the Bitcoin Blockchain doesn’t enable instant transactions required for a vending machine, we had to find a way to implement Lightning Payments instead.

The Lightning Network is a layer over the Bitcoin Blockchain, where people are able to process transactions without any time delay. It is one of the most promising solutions to solve the scalability issue of the Bitcoin Blockchain. This project was a perfect exercise to gain and spread Blockchain and Lightning knowledge in our team – and of course to help our colleagues get their snacks in a seamless way.

The problem

On October 31st, 2008 Satoshi Nakamoto wrote a message in a cryptographic mailing list, where he invited the participants to read his paper “Bitcoin: A Peer-to-Peer Electronic Cash System”. The first answer to this post was by James A. Donald. He wrote: “We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.” (Satoshi Nakamoto Institute, 2008)

It is incredible to think that the first concern ever formulated about Bitcoin is in fact it’s biggest issue. Take an event in July 2021 for  example. It took 25 minutes for the network to confirm a transaction, instead of the usual 10 minutes.  How could someone use Bitcoin as a currency with such lengthy transaction confirmation times? Waiting 10 minutes is already long, but 25? We are used to being able to pay for things in less than 30 seconds, or even quicker if by credit card. If we want to use Bitcoin as a payment method, there must be a way to process payments quickly, and with low transaction fees – especially in case of microtransactions.

The Lightning Network

These scalability problems are not new to anyone in the crypto space. Already in 2015 the first paper about a faster “second layer solution” was published. This was the paper that introduced the Lightning Network. The key element of the proposed solution was to minimize the transaction time of Bitcoin to just a few seconds by taking the transaction off the chain, which can be done with special wallets, which have to be funded with BTC. This network consists of channels designated for the cash flow between two participants.

A transaction in the Lightning Network occurs as follows:

1. Let’s say we have two users, Alice and Bob, who both own a bitcoin wallet. They both  agree to create a channel between each other. One of them  (let’s say Alice) agrees to fund the channel with a certain amount of money (e.g. 1 BTC). At that point, the technology allows only one user to fund a channel, but Lightning Network developers are working to enable both parties to do so (at the time of writing).
2. After both participants have agreed to open a channel with a certain amount of BTC, both participants exchange their public keys which they normally need for transactions on the BTC Blockchain.
3. A new BTC address is now created on the basis of these two public keys. This address is a special type, called “2-of-2 multisig address”. The unique aspect about this type of address is that both participants’ signatures are needed to validate a transaction. This address is a combination of the public keys of both participants.
4. The penultimate step in building a Lightning channel is to create a so-called refund transaction. As Alice is providing a certain amount of bitcoins for this channel, it must be ensured that it is possible to get the money back without having to trust the user called Bob. Therefore, a Refund transaction is created upfront, which has to be signed by both parties before anything further happens. The Refund transaction becomes valid as the corresponding Lightning channel is funded, which happens in the next step. Furthermore, this transaction is not written on the blockchain, but remains off-chain with the two participants in the Lightning network.
5. As soon as the Refund transaction is validated by both sides, the actual funding transaction is carried out. In this case Alice pays 1 BTC into the multisig address. Now the Lightning Channel is open and can be used for further transactions. Alice always has the possibility to get her Bitcoins back, thanks to the Refund transaction that is already signed and can be executed anytime by publishing it on the bitcoin blockchain.

At the current stage of development of the Lightning Network, there are no actual transactions in a lightning channel, but instead the Refund transaction is updated. As an example: Alice and Bob have a funded Lightning channel together. Alice owns 1 BTC and Bob owns nothing. This means that the refund transaction states a payback of 1 BTC to Alice and nothing to Bob. As Alice “transfers” 0.4 BTC to Bob, Bob will own 0.4 BTC, and Alice 0.6 BTC,as the original maximum funding is 1 BTC. The Refund transaction is updated to 0.6 for Alice, and to 0.4 for Bob. Each time the parties want to send each other BTC, there is no actual movement of the funds, only the Refund transaction is updated. Whenever the parties decide to close the channel, they can execute the Refund transaction, which will be then recorded on the actual Blockchain.

Development process of the Block Explorer

Following this, we split the project into three phases (ct. Fig. “Development Phases”):

• Construction of a prototype
• Addition of advanced features to the existing prototype
• Transition of the prototype to a system ready for production 

During the prototype phase our focus lay on the infrastructure and building the architecture. We needed to consider the fact that Blockchain clients are frequently  updated by their respective developers.

These Blockchain clients, which represent the basic backbone of the application, must be updated as soon as a new release is available. This is challenging because new versions are released frequently, and often at short notice. To minimize potential sources of error, we designed the Block Explorer in such a way that it does not rely on additional external sources. It relies directly on blockchain nodes to provide blockchain data. The correct operation was ensured by monitoring all nodes permanently. For this first phase, we involved software developers and a senior technical architect. After we considered different possible base architectures, we decided to go with a microservice architecture based on the containerization of each microservice.

In the next step we focused on stable and correct data acquisition and transfer from the different blockchains. We also implemented features to process data, meaning  analytical visualizations such as charts or graphs can be shown to the stakeholders. 

After it was ensured that the data was coming in and processed correctly, our designers and UI experts came on board.

Another task was to develop a User Interface based on the stakeholders’ analysis that was specifically customized to our client’s needs.

In addition, we also made sure the product has flexible interfaces that make it possible to link it to other systems. This was accomplished, as we managed a seamless integration into the customer’s existing ERP system.

The Lightning Network in real life scenarios

Without any research or analysis, it is pretty obvious that Lightning Payments are the most useful type of payment when it comes to small purchases. Low cost products that are usually paid with by cash or card are too small to take up precious space on the relatively slow and expensive Bitcoin Blockchain.

To name a few cases in which smaller payments are usual: (Tatge, 2020)

• Tickets for public transportation
• Vending machines
• Supermarkets
• Gastronomy
• Refuel or charge the car

The requirements of these real life purchases are all fulfilled by the improvements the Lightning Network brought to Blockchain technology: 

• Transactions without delay
• Microtransactions down to 0.00000001 BTC
• Relieving the burden on the Bitcoin blockchain by outsourcing transactions

Development

One of the most practical use-cases where the Lightning Network could be used as a solution, is in the case of a vending machine (Tatge, 2020). When the Lightning Network was launched in 2019, we immediately wanted to test it within our office. The most obvious way for us to do this was to implement it in a snack machine.  

We had to reprogram and remodel the machine so it could establish connection with the Lightning Network. We added a small screen that could work with QR codes, to enable handling BTC addresses.  The process of buying a snack then was as follows: 

1. The buyer choses a snack at the vending machine.
2. The machine creates a bill (called “charge” in the Lightning Network), which is displayed as a QR code on the screen.
3. The QR code contains the 2of2 multisig wallet address to which the buyer must send the BTC.
4. The machine checks whether the amount in BTC has arrived. This normally happens within seconds.
5. As soon as the machine recognizes that the correct amount has arrived it delivers the snack.

There is an App which can be used easily to participate in the Lightning Network and to purchase snacks from a vending machine, and it’s called Eclair. (Bitcoin.org, n.d.) This is the app we used for our vending machine too.

Conclusion

We remodeled a classic vending machine to accept Lightning Payments for testing a real life use case of the Lightning Network. . Our goal was to see whether we can enable quick payments with Bitcoin in case of small items in an everyday setting. We managed to find a simple way to reach this goal, and since then, we have successfully implemented Lightning Payments in other machines and used the Lightning Network in several other business transactions worldwide.

Bibliography

Bitcoin.org. (n.d.). Eclair Mobile. Eclair Mobile. https://bitcoin.org/en/wallets/mobile/android/eclairmobile/

Satoshi Nakamoto Institute. (2008, 08 31). Cryptography Mailing List. Bitcoin P2P e-cash paper. https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/1/

Tatge, L. (2020, 05 20). Analysis of use cases for the Lightning Network. Business perspective and value creation. https://medium.com/coinmonks/analysis-of-use-cases-for-the-lightning-network-bitcoin-2-0-cc8b7ac9ee5e

Abstract

Our client, a hedge fund specializing in energy and commodity trading, needed our help with a demanding migration project. They wanted to expand their trading operations to cryptocurrencies. Our task was to design and implement a solution that would improve their analysis processes.

In order to monitor and query data from the blockchain with the highest possible performance, a tailor-made Blockexplorer was required, as most functionalities are not covered by public Block Explorers.

Requirements engineering

Our client wanted to focus on six coins and consequently, six blockchains. Due to the rapidly evolving nature of cryptocurrency markets we were facing a tight timeline.

The six blockchains and the corresponding algorithms were:

• Bitcoin (SHA256)
• Bitcoin Cash (SHA256)
• Litecoin (Scrypt)
• Ethereum (Ethereum)
• Monero (Cryptonight)
• Zcash (Equihash)
• Dash (X11)

Another requirement was to implement  calculations and estimations based on blockchain parameters such as the difficulty, the hashrate and having an address watching feature.

Market analysis

A Block Explorer is not an entirely new tool, and there are already multiple Block Explorers on the market.

• Blockexplorer.com (Bitcoin)
• Etherscan (Ethereum)
• CryptoID (DASH)

These Block Explorers could have delivered the needed base data sets, but a deep analysis revealed the following downsides:

• Heterogeneous programming interfaces of each Block Explorer.
• Rate limits for requesting data
• No proof that the retrieved data is correct due to lack of access to the Blockchain Nodes

If our client had  decided to use existing Block Explorers and their data, we would have had to program our own software which provides a homogeneous interface to all blockchains.

After comparing both possibilities, the client decided to request a customized, trusted Block Explorer.

Development process of the Block Explorer

Following this, we split the project into three phases (ct. Fig. “Development Phases”):

• Construction of a prototype
• Addition of advanced features to the existing prototype
• Transition of the prototype to a system ready for production

During the prototype phase our focus lay on the infrastructure and building the architecture. We needed to consider the fact that Blockchain clients are frequently  updated by their respective developers.

These Blockchain clients, which represent the basic backbone of the application, must be updated as soon as a new release is available. This is challenging because new versions are released frequently, and often at short notice. To minimize potential sources of error, we designed the Block Explorer in such a way that it does not rely on additional external sources. It relies directly on blockchain nodes to provide blockchain data. The correct operation was ensured by monitoring all nodes permanently. For this first phase, we involved software developers and a senior technical architect. After we considered different possible base architectures, we decided to go with a microservice architecture based on the containerization of each microservice.

In the next step we focused on stable and correct data acquisition and transfer from the different blockchains. We also implemented features to process data, meaning  analytical visualizations such as charts or graphs can be shown to the stakeholders.

After it was ensured that the data was coming in and processed correctly, our designers and UI experts came on board.

Another task was to develop a User Interface based on the stakeholders’ analysis that was specifically customized to our client’s needs.

In addition, we also made sure the product has flexible interfaces that make it possible to link it to other systems. This was accomplished, as we managed a seamless integration into the customer’s existing ERP system.

Fig. 2: User Interface of the Block Explorer

The last phase of the project involved bringing the Block Explorer to a production-ready state. This included the ability of the services running to be replicated for gaining high availability, and ensuring the IT security of the product by executing an external audit by a third party company.

During all phases the team worked very closely with the client’s IT team to ensure their ability to maintain the Block Explorer after we delivered it.

The result of the architecture is shown in the following figure:

Fig. 3: Architecture of the Block Explorer

Customized features of the Block Explorer

The client wanted  to be able to implement a new blockchain anytime.  We were able to fulfill this request in a very short time, due to the architecture design we chose initially. In addition, the interfaces were able to show the results of the newly added blockchain directly and thus provide integration into the existing systems. This was all made possible without further effort due to the self-developed, uniform data structure and an excellent  understanding of our client’s requirements and the technology.

Another special extension that was requested much later in the development process was the address-watching-feature. The purpose of this extension was to allow the user to monitor certain wallets or transactions, and the blockchain.

A special feature that wasn’t even requested at the time, but was realized later due to the chosen architecture was the fact that any situation from the past can be used and simulated again in models. The data is on the blockchain and the Block Explorer provides the exact data in the specific interval desired by the client. This feature then became very useful for the client’s projecting models.

In the end, the Block Explorer became a general source of data, used for purposes beyond what our client had initially requested.

Further fields of application

The initial purpose of developing the Block Explorer was analytical research, but we were able to utilize it for further projects too.  For instance, the Block Explorer could also be used for quality control purposes, because it allows for comparison between results and data from other external sources (such as  in the case of profitability calculators).

We can proudly say that mining farms are using the Block Explorer to monitor mining pools, too. Many more use cases are likely possible, we just haven’t thought of them – yet!

Authors: Raoul Andersson, Christopher Becker
Editorial: Mia Molnar, Thomas Liebberger, Anna Lauterjung

Abstract

Our client, a leading hashpower provider in the crypto mining business, sought to tokenize hashpower and offer it to over 2,000,000 customers worldwide

The client requested a comparison between classic cloud mining products and this new concept of a hashrate token. Additionally, they asked us to develop an architecture concept for said token

Market Analysis

The first step was to conduct some market research. We discovered two existing products that were relevant for our case, and we proceeded to analyze them:

• Bitcoin Standard Hashrate Token (BTCST)
• Blockchain Mining Unit (BMN)

We found that neither product was suitable for our client, due to differences in the target group they were designed for, and lack of transparency. Governance principles could also not be clearly identified. Additionally, it was unclear how the client could integrate their own business method of cloud plans into these tokens. Our findings led us to the conclusion that the best solution for our client’s needs is a tailor-made hashrate token.

Business Analysis

For the analysis of the hashrate token concept we worked closely together with the sales department of our client. In workshops we analyzed the structures of existing cloud mining products and the user experience for their entire life cycle.

Usually, a cloud mining plan is structured as follows:
The customer buys a fixed amount of hashpower at a fixed upfront price in form of a plan.

There are two options of carrying  out this  mining plan:

• The plan ends after a fixed time period; the user gets their mining output only afterwards.
• The runtime of the plan is not fixed; the end of the agreement is determined by the natural depreciation of the purchased hashrate.  As the runtime is unknown at the beginning, the maintenance fee cannot be calculated upfront, and therefore, the provider must  deduct a maintenance fee from the user’s daily payouts. Due to the hashrate depreciation, at a certain point the maintenance fee is comparatively  so high that the mining plan is unprofitable and ends automatically.

The profitability of mining, and therefore a mining plan, is determined mainly by these two factors: The price of the mined cryptocurrency and the network hashrate which is directly related Mining Difficulty.

Requirements Engineering

For this phase of the development we added software developers to our project team. We based the architecture of the hashrate token on the following functional requirements:

F1: Tradeability
F2: Ability to offer different batches of tokens
F3: A cost reduction of 25% compared to classic cloud mining plans
F4: The mapping of business logic of cloud mining contracts to smart contracts

Apart from the functional requirements, some non-functional ones were defined as well:

N1: Scalability
N2: Sustainability
N3: Deeply tested platform
N4: Low cost of issuing of the token

Infrastructure

A major challenge was the fact that smart contracts do not work on the Bitcoin blockchain, and it was not possible to create a token on the Bitcoin blockchain. However, our client required a solution where the token represented Bitcoin hashpower and the token holder would receive their rewards in Bitcoin.
Following this, we looked at blockchains that did allow smart contracts. The token itself does not produce hashrate which is used for Bitcoin mining, but in fact represents the hashpower produced by the corresponding ASIC miners. The distribution of BTC mining rewards must occur on the Bitcoin blockchain via a payout middleware. Therefore, the token (smart contract) could only represent the hashpower, which was actually mining Bitcoin.

Based on the requirements defined upfront, there were two possible ways to go. One possibility was to use the Flow Blockchain, which became very popular with the introduction of NFTs. The other choice was the classical Ethereum Blockchain, which is well-known in the crypto ecosystem. The first step in choosing the right platform was to evaluate both technologies.

The following table shows the differences between the Flow and the Ethereum Blockchain, on which the decision process for the infrastructure was based on: (PixelPlex, n.d.)

Table 1: Comparison of Ethereum and Flow

While Ethereum currently remains the standard blockchain for developing smart contracts, Flow was developed specifically for the needs of NFTs. Due to the broad number of use cases and the resulting popularity and “crowdedness”, the Ethereum system can become cumbersome and expensive.

Flow is a Proof-of-Stake (PoS) Blockchain and relies on a network of validators that can take on four different roles (Consensus Nodes, Verification Nodes, Execution Nodes, Collection Nodes). (Flow Primer, n.d.) The Flow Blockchain, compared to Ethereum, is a new system, so we cannot assume this technology will stay the way it is now.

Both systems have clear advantages which are useful for the token creation process. As the business logic of cloud mining plans is not complex (Cf. Fig. 1), it is possible to represent them in both Blockchains. In the end, the decision was made in favour of the Ethereum Blockchain. The reasons for this are the use of Solidity as a programming language, which is the de-facto standard for coding of smart contracts nowadays. The other reason is the broad acceptance of the Ethereum Blockchain within the crypto ecosystem as a standard platform for smart contracts. Additionally, the Ethereum ecosystem has a well-defined set of possible token standards, which can be used in the implementation of the hashrate token.

Token standard

Choosing the infrastructure also determined the token standard. The following table shows the different token standards that were taken into consideration:

Table 2: Comparison of Token Standards

Our team worked hand-in-hand with the client and came to the conclusion that ERC-20 was not the best standard that fit our goals. The ERC-20 token does not have a proof-of-ownership mechanism, and without that, the central purpose of a hashrate token could not be fulfilled. While ERC-721 fulfilled most of the requirements, at the end, we decided to base the architecture concepts on the ERC-1155 standard, because it allows creating multiple batches of tokens without requiring a new smart contract every time. Furthermore, the client and developers had the freedom to choose the fungibility suitable for the token. Additionally, the ERC-1155 requires less storage space in the network, which reduces the costs of issuing and transferring the hashrate token. This feature makes this product more appealing to possible customers and stakeholders.

Our client requested additional features such as a burning mechanism and a payout engine. The burning mechanism is responsible for ending a cloud mining plan. The event of a so-called “Token Burning” is monitored by a dedicated Ethereum Node which then triggers the Bitcoin payout process.

Throughout this process we worked closely with our client’s IT team and their sales department to ensure that we offer concepts based on our client’s expectations.
At the end, we were able to deliver three different concepts, and all of them met the client’s criteria and goals.

At the end of this process the following ERC-1155 based architecture was developed:

Fig. 2: Flow Diagram of the Hashrate Token

Our team worked hand-in-hand with the client and came to the conclusion that ERC-20 was not the best standard that fit our goals. The ERC-20 token does not have a proof-of-ownership mechanism, and without that, the central purpose of a hashrate token could not be fulfilled. While ERC-721 fulfilled most of the requirements, at the end, we decided to base the architecture concepts on the ERC-1155 standard, because it allows creating multiple batches of tokens without requiring a new smart contract every time. Furthermore, the client and developers had the freedom to choose the fungibility suitable for the token. Additionally, the ERC-1155 requires less storage space in the network, which reduces the costs of issuing and transferring the hashrate token. This feature makes this product more appealing to possible customers and stakeholders.

Our client requested additional features such as a burning mechanism and a payout engine. The burning mechanism is responsible for ending a cloud mining plan. The event of a so-called “Token Burning” is monitored by a dedicated Ethereum Node which then triggers the Bitcoin payout process.

Throughout this process we worked closely with our client’s IT team and their sales department to ensure that we offer concepts based on our client’s expectations.
At the end, we were able to deliver three different concepts, and all of them met the client’s criteria and goals.

At the end of this process the following ERC-1155 based architecture was developed:

Conclusion

Our evaluation provided the foundation for developing a hashrate token which was later published on the Ethereum Blockchain. This approach was built for Bitcoin, which is a Blockchain based on Proof-of-Work consensus. There is a possibility to extend the use case of a tokenwatched like this, and to also develop it for other blockchains that use different consensus mechanisms.

Authors: Christopher Becker, Raoul Anderson
Editorial: Mia Molnar, Thomas Liebberger, Anna Lauterjung

Bibliography

Entriken, W., Shirley, D., Evans, J., & Sachs, N. (2018, January). EIP-721: ERC-721 Non-Fungible Token Standard. Ethereum Improvement Proposals. Retrieved August 3rd, 2021, from https://eips.ethereum.org/EIPS/eip-721

Flow Primer. (n.d.). Multi-Node Architecture. Multi-Node Architecture. https://www.onflow.org/primer#primer-multinode

PixelPlex. (n.d.). Flow vs Ethereum. Which is Best for NFT Development? Flow vs Ethereum: the Ultimate Comparison of Blockchains and Their Programming Languages. Retrieved August 3rd, 2021, from https://pixelplex.io/blog/flow-vs-ethereum-comparison-best-platforms-for-nft/

Radomski, W., Cooke, A., Castonguay, P., Therien, J., Binet, E., & Sandfort, R. (2018, June). EIP-1155: ERC-1155 Multi Token Standard. Ethereum Improvement Proposals. Retrieved August 3rd, 2021, from https://eips.ethereum.org/EIPS/eip-1155

Srivastava, R. (2021, April 4th). Token Standards: ERC20 vs ERC721 vs ERC1155. Token Standards: ERC20 vs ERC721 vs ERC1155. Retrieved August 3rd, 2021, from https://medium.com/coinmonks/token-standards-erc20-vserc721-vs-erc1155-3106f1e3f2f3

Vogelsteller, F., & Buterin, V. (2016, November 20th). EIP-20: ERC-20 Token Standard. Ethereum Improvement Proposals. Retrieved August 3rd, 2021, from https://eips.ethereum.org/EIPS/eip-20