Blockchain ideal consensus mechanism for Dapps used mostly on phones - blockchain

If we have an DApp that is running on a private chain, and mostly used by people on their phone. Let's say the application let's people exchange goods for tokens (basically an online platform). I see the advantage of implementing blockchain for two reasons: lower transaction fee / higher speed, and to be able to guarantee vendors certification.
Now what would be the ideal consensus mechanism, given users are using their phone, therefore low processing power. Allowing people to confirm transactions using their phone would make the chain an easy target for 51% attack (as it would require little processing power). Any alternatives?

Considering the scenario of phones as light nodes and factoring in the security challenges poised by 51% attacks, and looking at the need for providing vendor certification, a consensus algorithm like delegated proof of stake or proof of authority looks relevant for the following reasons.
In proof of authority, mining of blocks is not a necessary pre-condition and hence you can use mobile phones as the light nodes.
In proof of stake, the cost for 51% attack is substantial and inhibitive.
If we consider delegated proof of stake, the delegation time can be used as a check and balance for the leader to route the incoming proposals to the relevant node. There could be one device or a machine with good computing capacity which can act as a leader to other mobile phone based nodes.
If transaction fee and the transaction speed are constraints, you need to consider a Blockchain platform other than ethereum for proof of authority or proof of stake based implementation.

Related

Which blockchain is best to implement tamper proof document?

I am just starting out as a blockchain developer and I want a blockchain service except Ethereum (already implemented) to store a hash (SHA256 and ISCC hashes) of a document in a blockchain so that it can verify its validity and is tamper proof. There is already a UI to generate hashes and I need a blockchain to store the hashes
My need is:
I want to have a blockchain service with low transaction cost and high transaction speed. Also, I want that the hashes be stored in the blockchain for a long period of time (5 years). Which blockchain would be best fit for this usecase?
To answer your question, you need to understand who will be the users of your project. Accordingly, it is necessary to use the public or private blockchain further. For public blockchains, the choice is quite small - of those that will live for 5 years, these are most likely Bitcoin and Ethereum. For private blockchains, the choice is much wider: Ethereum / Quorum, Hyper Ledger Fabic, Corda and many others. Each of them has its own complexity of deployment, development and support.
But the very first question - why do you need blockchain? To store hashes of files, you can use IPFS or cloud storages, certifying them with a digital signature of a certain "notary" participant or, for example, the owner of the file. In terms of performance and low cost, these are the most efficient solutions.
I want to have a blockchain service with low transaction cost and high transaction speed.
Everyone wants this, so you are not along with your requirements.
Also, I want that the hashes be stored in the blockchain for a long period of time (5 years). Which blockchain would be best fit for this usecase?
Currently all blockchains assume the state is stored permanently - or to the end of the world or until nobody runs nodes anymore. Whichever comes first. There is a risk of dead chain, so whatever you pick might not be around after five years. However this is a business discussion, so it is hard to answer to this one on StackOverflow.
For your use case, it does sound you do not need a blockchain at all, but just having a public data storage that is prepaid for up to five years.
You can use Emercoin NVS for upload your hashes. Service emernotar.io already does so. Also, you can use File Validator service, all scripts are open source and available on Github.

Blockchain as a database for training certifications

I work in a company where in order to send staff to the field, employees have to comply with a certification that expires each 4 years, which probably employees did in their previous job, but the previous job just provided a letter that could be falsified, also, others companies don't spend time and resources to share their databases advocating security for the sensitiveness of data (names, nationality, id, company (including governments), date completion), centralization is a risk they don't want to take. As this is a training that is the same, and conducted everywhere that produces a contract between the company and the person, that expires in 4 years, but the person would like to be able to certify itself with the other companies, I was wondering if there is such implementation in the blockchain world, where writers, public ones, with no interest in 3rd parties, but in consensus due to the training nature, are willing to write/read the transaction on a secure manner providing a "self-service" among producers and consumers.
Assuming the other companies want to participate in the scheme, it is perfectly plausible to use some blockchain solution. You might want to use Hyperledger Fabric to create a privately permissioned blockchain network between the relevant stakeholders.
However don't get sucked into the blockchain hype, evaluate objectively whether the rest of the business processes also fit in the paradigm. Can certifications be revoked? Are there regulations on what data you can store on the employees and rights they have to get their data erased?
There might be many other simpler solutions that achieve the same thing. If the company or training provider just has a private key that signs certificates (PDF?) it might already be enough to solve your letter falsification issue.
Maybe each company could host its list of certified trained people on its own repository which could be queried, such that the list of certified people is maintained up to date (and any revocations can also be handled online), would probably achieve exactly the same result. Just like most other blockchain use-cases, there is a simpler solution that achieves the same thing, and is probably more flexible to fit the rest of the business processes.
Finally, before engaging in too much effort, make sure the other third parties are on-board. Do they really want to share the list of people they trained with competitors? If there is a likelihood they will not play along the project will probably be DOA. Case in point what happened here:
https://www.coindesk.com/ibm-blockchain-maersk-shipping-struggling/

how to use corda to design an interbank payment system

I recently learned, traditionally, interbank payment systems need following features to carry out tasks:
need a central bank to prevent parties involved from going bust.
need a clearing house to perform netting algorithms to minimise liquidity requirement.
If we use corda to implement a similar payment system:
do we still need central banks and clearing houses appearing in the networks as independent nodes?
If so, what do they do?
Do they serve as notary nodes or something else?
What relationships do they have with commercial banks?
Why this kind of corda-based design is better than traditional interbank payment system?
Corda has been used to develop a real-time gross settlement pilot in association with the Monetary Authority of Singapore. See the report here: http://www.mas.gov.sg/~/media/ProjectUbin/Project%20Ubin%20Phase%202%20Reimagining%20RTGS.pdf and the source code here: https://github.com/project-ubin/ubin-corda.
Using Corda removes the need for clearing houses. Netting and delivery-versus-payment/atomic asset swaps can be achieved without the need for a centralised party. Corda also removes the need for reconciliation, which happens automatically via the platform.
More importantly, Corda is driving towards a vision of global interoperability. See
https://medium.com/corda/universal-interoperability-why-enterprise-blockchain-applications-should-be-deployed-to-shared-3d4daff97754. In this vision, assets are not trapped in silos, and can move freely across the network. For example:
BankNode receives cash via the interbank payment system
BankNode lends this money to SupplierNode in exchange for an obligation
SupplierNode uses this money to purchase goods from FactoryNode
FactoryNode uses the money to pay the suppliers of its raw materials
And so on, and so on...
Coordinating things using a clearing house remains possible when looking at a single area like interbank payments. However, as the network grows to support many different business use-cases - supply chain, lending, assets, payments... - it becomes increasingly difficult to find a coordinating party that can be trusted by all parties, across industries and regions. Corda removes the need to identify such a coordinating party.
In this vision, central banks are likely to continue to exist as trusted issuers of fiat currency.

Difference between various blockchain protocols [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
As the developers are constantly using different network protocols of blockchain such as Hyperledger, multichain, Ethereum, Corda, and others. Community will appreciate if the developers & blockchain enthusiasts can pour in some key differences between various types of blockchains as mentioned above.
Thanks !
This is a good question, though not one easily addressed with a simple answer.
As #Mat0 commented above, one difference is the approaches that the various platforms are using to achieve consensus. Some use proof of work (PoW), others use variants of byzantine fault tolerant strategies (PBFT, SBFT, etc). Some use PAXOS derivative strategies. Hyperledger Sawtooth Lake has developed an innovative strategy named Proof of Elapsed Time (PoET). Some, such as Hyperledger Fabric allow pluggable consensus implementations to allow for experimentation and additional diversity.
Other platforms differ in the means by which they implement confidentiality of data and transaction execution.
Some such as Hyperledger Fabric, Hyperledger Sawtooth Lake, Corda, Ethereum and many others permit more comprehensive smart contract capabilities, while other platforms are very restrictive of the types of contract operations - such as the various platforms that only support the limited set of operations in the unspent transaction output (UTXO) protocol.
Some are more targeted to a specific use case, while others are more intended to be more general purpose. All are seeking to find ways to improve the various aspects of performance and scale.
Finally, some are intended to support permission-less public blockchain networks, while others are more oriented towards support for private, permissioned networks (consortia networks) where participation and membership is tightly controlled.
Hyperledger is focused on developing blockchain technologies suitable for use in the enterprise. The organization has been established to bring together related and even competing technologies in the expectation that the proximity and common governance will lead to interoperability and gradual consolidation.
Choosing a platform will demand significant research and a clear understanding of your use case and requirements and a good deal of experimentation. At the end of the day, there will be no easy answers.
To add to Chris's comment, with which I mostly agree, I'd expand on his comment about the "UTXO" model.
In our view (I'm the CTO of R3), one key design decision which distinguishes blockchain platforms is whether they use what I call the "replicated virtual machine" metaphor or whether they are based on the idea of transaction outputs (the "UTXO" model).
Mike Hearn wrote about this in the context of Corda's design: https://www.corda.net/2016/12/09/rationale-tradeoffs-adopting-utxo-style-model/
The key point I wanted to make, however, was that the UTXO model - at least as implemented in Corda - enables full-function code to be run... the set of supported operations is not in any way limited.
The differences become manifest mostly in the context of the non-functional characteristics of the platforms.
As Chris says, platform selection should be driven by use-case: I believe that the UTXO model we've used in Corda makes it particularly well-suited for a wide variety of financial services scenarios (that's why we made the choice to adopt that architecture!). But there is no one size that fits all.
Bitcoin technology stack — especially when enhanced with sidechains and payment channels (such as from Blockstream and Lightning Network).
Ethereum platform — currently the second most proven platform, behind the Bitcoin stack.
Hyperledger Fabric — a result of significant strategic investment from IBM and many others that is reaching into an installed base of large corporate customers.
R3 Corda — vertical-oriented blockchain technology (the company prefers "blockchain inspired" because it emphasizes significant differences between this private/permissioned ledger offering compared to the public/permissionless ledgers such as Bitcoin blockchain).
Digital Asset — another vertically focused blockchain technology that has high visibility in the financial services sector
While it is very difficult to predict the eventual winner given that it may not even be on the market, but it is possible to state what that winner will look like. Here are the 9 characteristics of a winning blockchain platform
Open source — this is necessary to cultivate a rich and diverse ecosystem and accelerate adoption through network effect.
Modular architecture with layers of programmability and customizability — as above, this cultivates an ecosystem and enables market adoption.
Global scale — scalability, performance and efficiency are essential if blockchain is to become the foundation for the "Internet of Money."
Multiple implementations of the core protocol — multiple, independently developed implementations ensure that the protocol is understood, well-defined and adds resistance to possible attacks (as occurred with the Ethereum platform in September 2016). This requires there to be an accurate and precise specification of the core protocol, as opposed to relying on one codebase that is not documented.
Hardened through public blockchain deployment — this is the only way to ensure that the system is secure and "bulletproof," by exposing it to the worst threats on the open internet, as has occurred with both the Bitcoin stack and the Ethereum platform.
Configurable for private blockchain deployment and support for confidentiality of transactions — because most businesses do not want their transactions to be visible by their competitors or by the rest of the world.
Functioning governance — there needs to be a cohesive decision-making structure that can respond in an agile and coherent manner to threats to the system.
Advanced smart contract capability — because the current generation of smart-contract technology relies on traditional languages (similar to Java or C#), which are inadequate for the rigorous requirements of large-value contracts (and are best supported by metadata-driven or mathematically verifiable programming systems).
Adequate tooling for developing, debugging, deploying, monitoring and managing smart-contract-based systems (the importance of which was underscored by the recent denial-of-service attacks on the Ethereum network).
Since 2008, when the term bitcoin was coined by Satoshi Nakamoto as a novel electronic and completely peer-to-peer cash system free of trusted third party, the interest in the bitcoin and blockchain technology has increased. Recognizing it as a revolutionizing technology across the industries, especially in banking and finance, in terms of transactions and their privacy and security, researchers are not leaving any stone unturned to come up with exotic protocols with each passing day and each is the newer, advancer and better protocol than the previous. In continuation to the blockchain series on TheBlockchainAcademy.com, I have included 6 major blockchain protocols, so as to embrace the technology and increase awareness among investors and end users of blockchain.
Hyperledger
Hyperledger is the open source blockchain platform, began in 2015 by the Linux Foundation, in an effort to support the blockchain-based distributed ledgers. The protocol focuses ledgers developed to support international business transactions, catering leading financial, technological and supply chain businesses, with the objective of improving a lot of performance and reliability aspects. The project emphasizes on making collaborative efforts for making open standards and protocols, by offering a modular framework that backs various components for diverse uses, including a range of blockchains having their own storage and consensus models, and the services for access control, contracts and identity.
Bitcoin
The starting of the bitcoin dates back to November 2008, when a thesis had been posted by Nakamoto on a US mailing list where the cryptographers share or exchange information. The thesis titled “Bitcoin: A peer-to-peer electronic cash system”, presented the following characteristics of this protocol:
Enables transaction directly with no need of any trusted third party
Enables the non-reversible transactions
Decreases credit cost in minor casual transactions
Decreases transaction fees
Prevents double-spending
Bitcoins are virtual currency, also called cryptocurrency. These are distributed while exploring the value in the data managed by software. The start of 2016 witnessed the issuance of around 15.26 million BTC, equivalent to around 7 billion US Dollars. Major technologies that make Bitcoin include hash, digital signature, public-key cryptography, P2P and Proof of Work. This blend has developed a mechanism that prevents duplication of payments and data falsification, additioinally a mechanism that prevents malicious users, which are critical for the operating system like the one for the electronic money, having no central authority.
Ethereum
Ethereum is a public, open-source and block chain oriented distributed computing protocol that features smart contracts (scripting) functionality. The protocol has provided a decentralized virtual machine called the Ethereum Virtual Machine (EVM), which carried out Turning-complete scripts by using a global network of public nodes and the token called ether, also referred to as gas. Gas is used for preventing the spam on networks and allocating the resources in proportion to the incentive provided by the request. Bloomberg explains Ethereum as shared software that is used by all; however, is tamperproof. Ethereum is also used as a protocol for decentralized applications, smart contracts and decentralized autonomous organizations, with a number of functioning applications developed on it by March 2016, New York Times says.
Ripple Consensus Network
The Ripple Transaction Protocol (RTXP), issued in 2012, has been developed upon an open-source distributed consensus ledger, Internet protocol, and native currency termed as XRP (ripples). Ripple enables instant, safe and almost free global financial transactions of any scale without any chargeback. The protocol is embraced being able to support tokens presenting cryptocurrency, fiat currency, commodity and any other value unit like mobile minutes, frequent flier miles etc. By the end of 2017, Ripple is expected to be the third-biggest cryptocurrency in terms of market capitalization, after the bitcoin and ethereum.
R3’s Corda
Corda by the Company R3 is the distributed ledger protocol that has been developed from the ground up for recording, supervising and synchronizing the financial agreements among regulated financial institutions. It is, by great deal, stimulated by, and captures the advantages of blockchain systems, with no design choices that turn blockchains unsuitable for a lot of banking scenarios. Corda’s design came up as a result of heavy analysis and prototyping with team members. It is now an open sourced protocol since the code matured further.
Symbiont Distributed ledger
This protocol was announced in October 2016 as a software development kit for the Assembly, which is the permitted distributed ledger part of Symbiont’s smart contracts system. Assembly is considered as the first distributed ledger suitable for institutional finance. It is a greatly secure, high performing Byzantine fault-tolerant distributed ledger, which can process a sustained 80,000 transactions every second in a local multi-node network. As stated by Co-founder of Symbiont, decentralized systems should no longer be slow and with Assembly, it has been fulfilled.
You can learn more about Blockchain and implementing your own Blockchain # IBM Blockchain 101: A quick-start developer guide
This is the subject of a number of recent academic papers, as the field expands rapidly.
These for example are based on Consensus in the Age of Blockchains:
Committee Formation - How the members of the committee are chosen, for example via proof-of-work, proof-of- stake,
trusted hardware etc
Consistency - The likelihood that the system will reach consensus on a proposed value; it can be either strong or weak
Incentive Model
Safety ( Transaction, Censorship Resistance, DoS Resistance)
Adversary models considered
Performance (Throughput, Scalability, Latency)
Exp. Setup
Code availability
See also Blockchain Consensus Protocols in the Wild.
The main thing that differentiate each different blockchain is the consensus algorithm. Some algorithms are meant for public chain (eg: bitcoin blockchain) whereas some algorithms are meant for permissioned network (eg: Ripple, Hashgraph).
I will be bold and say that Confidence Coin is perhaps the fastest blockchain technology in terms of broadcasting events.
Better encoding. Every time a new address is used in a transaction it is saved to the blockchain database, so next time it is spotted it replaced with a numeric value. Bitcoin can encode about 2K transactions in one megabyte of a block while Coco can have up to 100K transactions in same space.
The principal problem in blockchain P2P networks is their size, with each new node added to the system it takes more time to broadcast new blocks to everyone. There are 11,000 nodes in Bitcoin as of 2018. The source of Coco speed is in its Royal Network. It's called royal as in order to join the network you must mine a block. It allows only the best Pools to be part of the Royal Network. It's funny as in Bitcoin over 95% of the blocks mined by less than 20 Pools, but instead of direct communication between them, their messages traverse the entire 11,000 nodes.
Disclaimer: I am the developer of Coco.
There will be several difference between those blockchain projects:
Application: The specific application or domain they are focusing on. Some blockchain projects are public basic blockchains, like Ethereum, you can develop your own applications on it with the support of smart contract. While others may focus on certain domain, such as entertainment, storage, finance etc.
Consensus Protocol: as mentioned by others as well, different blockchain projects may use different consensus protocols, such as: PoW, PoS, DPoS, BFT, DBFT etc. So many consensus protocols were proposed. Although, honestly speaking, for now, only PoW works well for a long time.
TPS: it's actually related with the 2nd point, consensus protocol can certainly affect the performance/TPS, however, block design, and technologies like sharding, lightning network can significantly affect the TPS as well. Specific technologies used to improve scalability can also differentiate those projects.
Smart Contract: programming languages used to develop smart contract, whether the contract is secure, whether the development environment is user friendly, those are also the factors that should be considered to differentiate the blockchain projects.
This is a very broad question. In short each protocol was built with rules to potentially address a particular objective or business use case challenge.
So the answer to your question can be narrowed by differentiating the purpose for each protocol is built.
Blockchain protocol solves decentralized ledger
Ethereum protocol solves decentralized ledger ,enable decentralized applications and smart contracts
Ripple protocol solves not only decentralized ledger, smart contracts but also addresses speed and cheaper transactions
Hyperledger Fabric solves providing restricted access to decentralized ledger.
R3's corda solves decentralized ledger for financial sector with no need for mining
Therefore each protocol has logic and rules built trying to solve the primary objective it chose. However the underlying concept is still the blockchain for each of the protocols.
Hope this answers your question at high level.

How to create a Distributed Ledger

I'm new to Blockchain but I do understand the concept behind it. My question is can we only contribute to blockchain through chaincodes or can we also create a distributed ledger? And also where does the Ledger gets stored?
There are many ways to implement a distributed ledger, blockchain is one way, but there are many new and exciting alternatives.
For example (prior art), Amandla-3i-Backbone uses an architecture where agents execute on a host. Essentially, a transaction is committed in just over 10 steps.
Amandla-3i-Ecosystem
Step 1
An arbitrary Agent decides to make a transaction. This Agent can be embedded in any product, such as an Android mobile application.
In this example, the application is transferring money to another user.
What is not shown in this step is that the Agent would need to locate a suitable Trade-Agent to conduct the transaction. This could be hardwired into the application, or it could have access to another Trust-Agent that could forward the details of a reputable Trade-Agent.
Step 2
The Agent describes the transaction it wants to the Trade-Agent which will conduct the complex workflow on behalf of the Agent requesting the transaction.
Note that the Agent is renting processing power from it’s local Node, and will be charged by the Trade-Agent for all work done. This monitisation means that economic type attacks are not possible.
The first thing the Trade-Agent does is contact the Buyer-Brokering-Agent directly.
It’s important to note that the Buyer and Seller do not interact directly, because Trust-Agents need to witness each transaction so that Brokering-Agent don’t oversell their currency at a high rate of exchange. An analogy would be a government printing too much money. It would be the Trust-Agents that would need to signal a devaluation in the appropriate Brokering-Agent currency if they witnessed this economic theft from taking place.
Step 3
Just after informing the Buyer-Brokering-Agent of the upcoming transaction, the Trade-Agent connects with a number of Trust-Agents that will witness the transaction. This could be a high number (possibly as much as 7 or more) of Trust-Agents. It is in the interest of the Trade-Agent to authenticate this transaction with a high degree of trust in order for the Trade-Agent to maintain its credibility on the network, since it is also rated by other Trust-Agents. It is likely to choose agents that have verified their execution and code to ensure there is no cheating. Only 2 Trust-Agents are shown on the diagram for descriptive purposes.
Step 4
The Trust-Agents begin the chaperoned trade by connecting to the same Buyer-Brokering-Agent and present the trade that they intend to witness.
Step 5
In the meantime, the original Trade-Agent connects to the seller and establishes the upcoming trade.
Step 6
Also simultaneously, the Trust-Agent also connects with the Seller-Brokering-Agent and signals their role as witness.
Step 7
Once the Seller-Brokering-Agent is informed of the transaction, it also makes a connection directly with the Buyer-Brokering-Agent and performs the chaperoned transaction.
Step 8A and Step 8B
Both the Buyer-Brokering-Agent and the Seller-Brokering-Agent connect to each of the Trust-Agents that are witnessing the transaction as part of the authentication process.
Step 9
The Trust-Agents confirm that the transaction was successful.
Step 10
The Trade-Agent completes the transaction.
Distributed Ledger Transaction Diagram
Example call
Sample call
note: I'm not an expert, I'm a student.
a ledger is composed of the data in the blocks of your blockchain. the schema of the ledger is agreed upon in advance (in the protocol of the blockchain), and trust is assured through the design of the ledger, mechanics of the blockchain, and often the proof of work in writing the next block.
blockchains don't need to be multi-party, they only need to be multi-party to be very useful. blockchains can be distributed by utilizing the network layer, with an eye to scale and trust: a large number of participants or important work should require good proof of work and/or other security measures. Trust can even be ensured by giving certain parties higher rights than others, but this is more useful in industrial uses than in digital currencies.
an example of a network solution that is suitable (but cumbersome) to use for custom blockchains is peerJS (I'm fairly sure it is sufficient). In essence though, the entire thing can be written over connections such as webRTC or raw network connections.
an alternative to writing all of this yourself is to use a general purpose ledger with composable contracts, like etherium or IBM's hyperledger. However, I would argue this is less than ideal for learning about the technology.