by SPR | 30 September 2021 | Ask Datarella, Blockchain
A bug bounty program is used to inspect protocol code and rewards inspectors if bugs are found successfully. Code and product quality can be increased significantly by such swarm intelligence. Therefore, MOBIX stands on a solid foundation as it leverages the Fetch.ai blockchain.
Even the best developers make mistakes. In order to gradually eliminate resulting bugs, a good solution is to motivate numerous competent inspectors to search through protocol code and identify weak spots in the code. Such vulnerabilities may be lucrative for blackhat hackers, so it is important to create appropriate incentives for whitehat inspectors to work as thoroughly as possible. Considering the follow-up costs that programing errors can result in, this can often be a very sensible investment.
Bug bounty programs are open to the public for this purpose, in order to acquire as many technically skilled inspectors as possible for a bug hunt. So-called “Full Disclosure” documentation discloses the program bugs completely publicly, while in the “Responsible Disclosure” model, only the originator is informed about the bugs for a limited time to have enough time to solve the problem. Responsible Disclosure is usually utilized when bug concerns a severe vulnerability to a live system which has not yet been exploited by attackers. One such case was the Zcash Counterfeiting bug discovered by the Electric Coin Co. in 2019.
Our partner, Fetch.ai launched a bug bounty program which ran from mid-2019 until the recent migration to the mainnet, which took place on 20 September 2021. There was a public call to inspect the code on Fetch.ai‘s Github ledger repository and report bugs as a Github issue, ranging from critical to low risk level. Depending on the severity of the bug, a reward of up to $10,000 in FET was available.
We mention this because our latest project, MOBIX is deployed to the Fetch.ai blockchain. In essence we’re able to leverage both the Cosmos SDK and Fetch.ai as a foundation for MOBIX. Due to the bug bounties run by Fetch and by the Interchain Foundation to assure code quality the chances of any kind of problem is significantly minimized.
by Martin Schäffner | 14 April 2021 | Ask Datarella, Blockchain
It is no secret, Ethereum, the by market cap and adoption most successful smart contract blockchain, is at its limit. Various DeFi apps, like Uniswap, Aave, games, like Axie Infinity, NFT marketplaces and issuing protocols, like OpenSea and Rarible and countless transactions and other smart contract interactions are clocking up the network. Sidechains and Layer 2 solutions are here to tackle the scaling problem of Ethereum until its transition to Ethereum 2.0 in completed.
For each transaction on Ethereum a certain amount of Gas needs to be paid. The amount depends on the computational effort. A simple transfer of ETH costs 21.000 Gas while a trade on Uniswap can cost 250.000 Gas. Miners of the network set the Block Gas Limit, which specifies the amount of how much Gas can be included within one block. This limit is currently set to around 12.5 million. A new block is minted roughly every 13 seconds. Which transaction is getting in the next block is determined by the Gas Price the sender is willing to pay. To make an example, at the current Block Gas Limit 595 simple ETH transactions could be process, rounding to 45 transactions per second.
Solving the scaling issue of Ethereum
Since ETH 2.0 is still under development various teams are working on solutions to solve the scaling problem of Ethereum. Most scaling solutions can be categorized into Sidechains or Layer 2 solutions. The main difference between Sidechains Layer 2 solutions lies in their security mechanisms.
Sidechains
The term Sidechains describe blockchains with own consensus mechanisms, which are compatible with Ethereum. Examples are the xDai and Polygon network. xDai used a delegated proof of stake consensus mechanism, which allows for fast and inexpensive stable transactions. A transaction does not take longer than 5 seconds and 500 of them cost only around $0.01. A bridge between xDai and Ethereum makes it possible to transfer any ERC20/677/827 tokens between the networks. This scaling solution is used from various NFT minting platforms, like Nifty Ink, or DAO infrastructure providers.
Layer 2
In contrast, Layer 2 solution do not have their own consensus mechanism but rely on the security of Ethereum. An example of Layer 2s are Roll-ups, which describe off-chain aggregation of transactions inside a Ethereum Smart Contract. You can differentiate between ZK-Rollups and Optimistic Roll-ups.
With ZK-Rollups, funds are hold by the smart contract on the mainchain. Computation and storage are done off-chain while validity is ensured using zero-knowledge proofs. A project with works on ZK-Rollups is Loopring.
Optimistic Rollups, are using a challenge period of 1-2 weeks to challenge fraud in case the aggregator has submitted an incorrect transaction. Therefore, you are “optimistic” on the submitted transactions. A project using Optimitic Rollups to scale Ethereum is Optimism. Its launch is planned for July 2021. Uniswap is currently running a demo version, Unipig, on Optimism, which only required 143x gas costs and allows for transaction in milliseconds.
Conslusion
Sidechains and Layer 2 solutions are an essential element to solve the scaling problem of Layer 1 protocols. It will be interesting to see what will happen to them when hyper scalable Layer 1 solutions arise, like Ethereum 2.0, Solana, Elrond, and many more.
by Rebecca Johnson | 5 August 2020 | Ask Datarella, Blockchain
People in the blockchain space often throw around the words Byzantine Fault Tolerant (BFT) as though it was self-explanatory. Additionally, BFT often pops up in discussions about consensus mechanisms. If you look closer, in the consensus algorithm space there are lots of variants. there’s pBFT, Tendermint BFT, BFT Raft, IBFT, and Lisk BFT to name just a few. This short post seeks to clear up the confusion.
Let’s start with what BFT isn’t. BFT, or Byzantine Fault Tolerance is not a consensus method. It is not a security model. It is not a specific technology. It is not exclusive to blockchain or exclusively useful in blockchain systems.
A system can be described as Byzantine Fault Tolerant if it provides a method for solving the byzantine general’s problem. This is a problem in computer science wherein, the system handles malfunctioning or unreliable components that give conflicting information to different parts of the system.
Lamport, Shostak and Pease described it in a Microsoft research paper in 1982 thusly:
This situation can be expressed abstractly in terms of a group of generals of the Byzantine army camped with their troops around an enemy city. Communicating only by messenger, the generals must agree upon a common battle plan. However, one or more of them may be traitors who will try to confuse the others. The problem is to find an algorithm to ensure that the loyal generals will reach agreement.
Byzantine Fault Tolerant, is at its core, a term that works as an adjective, and which as we have seen is often integrated into the names of various technologies to describe what they do. Any technology or system that has mechanisms for disregarding unreliable inputs from dishonest participants and reliably agreeing on a global state with only valid inputs from honest players can be seen as Byzantine Fault Tolerant. As such there are many security models and consensus algorithms that can be said to be Byzantine Fault Tolerant.
Additionally, underlining the fact that BFT isn’t a security model or blockchain specific consensus algorithm, BFT architectures are commonly used in military command and control as well as spaceflight and aircraft control systems. Two prominent real-life examples of BFT systems outside the blockchain space include the ARINC 659 SAFEbus network used for flight control on the Boeing 777 and 787 aircraft and SpaceX Dragon Capsule systems for approaching the International Space Station in case of multiple computer failures.
by Martin Schäffner | 6 April 2020 | Ask Datarella, Blockchain, SSI
Self-Sovereign Identity (SSI) is increasingly mentioned in connection with innovations and digital identities. Even in the context of the coronavirus crisis, SSI finds possible applications, such as the possible use of a tracking app for infected people or as a digital staff “passport” in hospitals that respects each user’s privacy. To support others in classifying SSI correctly, we are now publishing a series of blog posts that explain components of SSI. The first part of the introduction to Self-Sovereign Identity focuses on the three essential components – DIDs, DID Documents and Verifiable Credentials.
As already described in detail in the first blog post, Self-Sovereign Identity offers the user the possibility to manage their own digital identities completely autonomously. There is no platform or provider, such as an email address provider or a social network that controls identity. This is achieved using an underlying blockchain or a DLT on which key pairs can easily be generated that serve as identity representation.
Decentralized Identifiers
Now we come to the first component – the Decentralized Identifiers (DIDs). Their purpose is to act as a unique identifier of the person or object. These are derived from the public keys and can be identified over various blockchains. An example DID is shown below.
DIDs follow a general syntax: the schema (did:), the method (sov:) and the method-specific identifier (WRfXPg8dantKVubE3HX8pw). While the scheme is always the same, the method that describes how a DID is derived from a blockchain (here: Sovrin) and the method-specific identifier bo depend on the underlying blockchain. However, DIDs alone don’t bring any value.
DID Document
What fills a DID with life is the DID Document. This piece of data describes the DID object and its properties. By default, it contains the associated public key to a DID. However, it is also possible to add more public keys to the DID document that are authorized to perform actions in the name of a DID. Moreover, a DID can contain different types of attributes and service endpoints that allow the actual interaction with a DID. Changes to a DID Document can only be made by authorized public keys defined in the DID Document. An example DID Document with authorized public keys.
Verifiable Credentials
Now, that it is possible to identify an entity and to interact with it, is possible to attach information to the digital identity. This can be done with Verifiable Credentials (VCs) that act as an attestation or a digital representation of a credential such as an ID, a driver’s license or a club membership card. A VC consists of three main values:
-
- The issuer’s DID and signature
- The entity’s DID
- The information that is attached
Based on these three fragments, third-party verifiers can immediately determine the authenticity of the object by looking up the issuer’s DID. Verifiable Credentials are in possession of the DID owner that it was issued to and can be stored in a wallet. However, the issuer can always revoke the VC and adding it to the revocation registry that should be publicly visible.
These three components serve as the basis for a decentralized, trustless identity ecosystem that doesn’t rely on centralized authorities. DIDs identify an identity over, the DID Document describes the DID and a Verifiable Credential attaches verifiable information to a DID. Users are in sole control of their identity and can decide how information is shared and with whom.
However, this was only a small part of the entire SSI infrastructure. Part 2 of the Introduction to Self-Sovereign Identity components is about DID resolution, the process of resolving a DID Document from the DID, and DID authentication.
If you have any questions about SSI or want to leave feedback, feel free to contact me.
by Kira Nezu | 11 September 2019 | Ask Datarella, Blockchain
If you’re wondering why a blockchain company like us is writing a blog post about killing vampires, or if you’re confused because you’d think that meat products good for barbecue have nothing to do with our core competencies, you’ve landed in the right place!
This is a short explainer and introduction to proof-of-stake (PoS), which in the context of blockchain and distributed systems is a method for agreeing upon what is the true informational state of a distributed system. This is called the consensus mechanism in blockchain-talk and is often compared to proof-of-work (PoW), which is based on the simultaneous computation of many, many relatively simple calculations.
How does it work?
Proof-of-Stake is a process which starts with a pseudo-random number. This number is used to perform a lottery to see which node gets to validate the next block. And this is where the stake comes in. The probability of a node being allowed to validate a block can be based on the percentage of tokens that node has staked. The chosen validator then proposes a block. Some types of PoS allow for nodes with more stake to have more votes on the validity of this block.
In order to motivate nodes to participate honestly in the validation process, there are rewards and penalties in most PoS-models. The rewards are there so that someone will perform the common good of validating transactions, and the penalties are there to prevent corruption or attacks on the blockchain. One widely discussed attack is the nothing-at-stake attack which is when a node attempts to create blocks, or vote for all blocks, on top of many or all of the competing chains in an non-finalised state. It is in fact even in the interest of all rational nodes to do this, since the marginal cost is very low. For a penalty to be able to control for this type of behaviour, we need to know the full set of validators which are allowed to stake before the fork takes place, but then it’s easy to create a negative reward for those voting for multiple blocks. Another method of penalising validators for misbehaving is to create so conditions for when a validator is deemed dishonest beyond reasonable doubt. If this happens to a validator, the staked tokens are slashed. More here and here.
Why is PoS an improvement for blockchains?
Two reasons mainly:
- It requires less energy. The wasted-energy argument of many blockchain discussions is based on the assumption that blockchains use PoW. I won’t get into the details of how PoW works here, but since PoS doesn’t require any racing to find a special key between different nodes like PoW, the energy consumption is drastically improved.
- Economic incentives can be programmed into the model in a more certain way than in PoW. For example, centralisation cartels can be prevented by improved game-theoretic design and 51% attacks can be made incredibly expensive.
It should be noted that just as with many other parts of blockchain technology, there is room for development and innovation in staking protocols. There is already many different types of PoS with each having their own benefits and drawbacks. Hopefully, after having read this introduction, you feel empowered to dive deeper in other aspects of consensus mechanisms and blockchain!
by Martin Schäffner | 25 July 2019 | Ask Datarella, Blockchain
In casual discussions about blockchain and DLT it’s easy to mix up anonymity with pseudonymity. People often use the one term when they mean the other. There is a small but important difference we’ll explore in this post.
On the one hand anonymity describes the situation when the identity of an acting party is completely unknown. When the acting party is truly anonymous, there is no way to link the anonymous identity to a real world person. On the other hand pseudonymity describes the situation when an acting party has a consistent identifier that is not the real name but which might be linked with the real world identity of the person behind the pseudonym. As long as the link between the two isn’t known no one knows who the real identity behind the pseudonym is. But if those two can be linked, the identity is publicly known forever. An easy to understand example is the use of pen names by artists or authors who wish to address a market segment not usually associated with works published under their own names. Stephen King for instance published many books under his pseudonym, Richard Bachmann.
What does this mean for Blockchain?
Most blockchain technologies like Bitcoin or Ethereum rely on transparency and persistency. This means that the balance of every address and every transaction is publicly visible and irreversible. The addresses are the identifiers of the identities, and are anonymous until used. When used, the address takes on more pseudonymous characteristics. When a public / private key pair is created, the public address, is the pseudonym of the identity. But if the pseudonym got linked with the transacting party’s real world identity, all transactions will be linked to that identity.
Some blockchains have much more limited transparency and higher anonymity. Monero and ZCash are both examples of such chains. The identities used in those systems are mathematically non-identifiable, unreachable and untraceable due to the use of zero-knowledge proofs. These proofs only prove information about the fact that a transaction occurred without leaking any information about which actors or addresses took part.
Moreover blockchains can be implemented as either public or private chains. In contrast to public blockchains where information is publicly visible, private blockchains open the transactions only to parties authorised to use and see the information. This option is mostly used for blockchains operated between industry partners.
In the end analysis, most blockchains aren’t anonymous but rather pseudonymous. Addresses represent an identity that isn’t publicly known by default but theoretically could be linked. Despite this, zero-knowledge proofs offer a chance to keep the maximum level of anonymity possible in open blockchain ecosystems.
If you have more questions about anonymity and pseudonymity in blockchains, feel free to contact us.
by Rebecca Johnson | 16 July 2019 | Ask Datarella, Blockchain
People often ask us if our our blockchain solutions are energy efficient. There’s a lot of articles and good research out there indicating that the most famous blockchain, Bitcoin, uses as much energy per year as a small country. Let’s take a quick look at the myths and the reality in industrial settings.
The Myth: “All blockchains use large quantities of energy.”
The Reality: All blockchains DO NOT use large quantities of energy. Not all blockchains are the same and not all use cases require the same “blockchain”.
Bitcoin uses a consensus mechanism known as Proof-of-Work (PoW) to secure the network. While this approach has some advantages, there are other options for both, private and public blockchains, which don’t cost significant energy and still result in a secure network. For industry, it usually makes sense to utilize a private consortium blockchain with Proof-of-Authority (PoA) validators operated by consortium members. This approach effectively cuts the electrical consumption to almost zero. The level of decentralization, trustlessness and security that Bitcoin provides is way over the top for the vast majority of practical blockchain applications in industrial settings.
Additionally, even in situations where a public permissionless system is needed, there are a myriad of options regarding the choice of consensus algorithms which don’t consume exorbitant amounts of energy. Modern Proof-of-Stake (PoS) systems secure the network by requiring network validators to put up a “stake” (i.e. reserve) of tokens which can be automatically taken away or “slashed” if validator nodes attempt to cheat the system.
Bottom line: energy consumption isn’t an issue for us when working with industry partners. Consider the myth debunked.
