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.
Related
I'm documenting in this blockchain world. Basically I would like to make some web application in which a user decides to make a donation, and would like to see who made the donation and to which entity. I have several doubts, the first one:
1-Is it possible to use blockchain using javascript? (can smartcontracts be done in javascript?)
2- If the donation is made using blockchain, is it necessary to use a cryptocurrency? or you can use real money and make the transaction (using some means like paypal)
3- Can real money be transferred by some means such as paypal using blockchain?
Thank you very much, your answers will document me much more
Is it possible to use blockchain using javascript? (can smartcontracts be done in javascript?)
Every blockchain has a SDK, the part of the software which lets you
interact with the real blockchain( A decentralise ledger). There
are generally two parts in the Blockchain , One is client and one
is processor.
As you must have guessed, Client is the one who sends the transaction,
This transaction must satisfy certain rules in order to be accepted by
the transaction processor. If the transaction gets validated by
transaction processor, The transaction will be added to the block alongwith
other transactions and this block will then be added to the blockchain.
Copied to all other nodes (Forks are a different story)
Generally Most blockchains lets you interact with the blockchain through
ABCI which is just an interface to convert your transaction into
a format understandable by the blockchain processor.
Some blockchains has their fixed transaction processing logic like Ethereum for
security and some lets you write your own transaction processing logic like
Sawtooth, Fabric etc.
Permissioned and some public blockchains like Hyperledger projects and
cosmos SDK lets you write your own application layer logic for Blockchain,
So yes, You can write those transactions in Javascript or any other programming
language, as long as it satisfies the interface.
Public blockchain deals with tokens having real worth. Their transaction logic
is already fixed, but some of them does provide javascript API's like NEO
(Not sure about that)
2- If the donation is made using blockchain, is it necessary to use a cryptocurrency? or you can use real money and make the transaction (using some means like paypal)
You can do that and put the donation receipt on Blockchain linked with
real identities of people. This way if anybody wants to check who pays
how much donation, They can query blockchain for the user address.
3- Can real money be transferred by some means such as paypal using blockchain?
This can also be done, but this will involve using a crypt exchange,
centralised or decentralise. You can convert the real money into crypto
of your choice at one end and vice versa at the other hand.
Note: This is based on my limited knowledge of Cryptocurrencies. Please consult more people or any professional company before acting on this advice.
I don't think any protocols offer the possibility to implement their smart contracts in Java Script, but you can build a translator between the two languages which could potentially benefit others in the open source community.
So you want have some engineers do some work for you, in this case build an web application. There are several ways you can get this done, here are some ideas:
a) issue tokens which pays profits based on the success of your new business, you might be able to do this on a protocol that is not tied to any specific crypto or fiat currency.
The users can use an exchange to convert your tokens to their favorite one.
b) approach a private equity or VC fund and get them to pay for it.
c) forget about blockchain, and just pay for the project to your favorite engineers.
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.
In the "Coffee with Blockchain" app produced by IBM it performs price matching between Growers and Buyers. I'm wondering how that matching would be implemented (either in the example app or in an actual implementation).
Example of the app can be seen here: https://www.youtube.com/watch?v=suE5KHkESF4
How does "Coffee with Blockchain" match growers to buyers?
Some questions to help guide the answer:
Does that matching operate entirely as chaincode? If so, how would that be implemented?
Eg, would the Grower submit a transaction that they have a new batch of beans ready for shipment and that triggers the match-making part in the chaincode to find/choose a Buyer?
I have my doubts on making that process deterministic, otherwise a grower's new batch announcement fails and they'd have to retry. Perhaps there's a different way of doing so in chaincode?
Or does the matching operate outside of the chaincode, listening for updates in the ledger, and instead it calls the API to invoke a chaincode method to transfer the beans from Grower-A to Buyer-B?
My doubt on that though is the matching is then centralized to some trusted provider, rather than validated/endorsed chaincode.
Thanks
I can only hypothesise based on my understanding of Blockchain. IBM's algorithms are not public, so I do not have first hand knowledge.
But from what I know - Yes, all your understanding seem accurate.
Unlike crytocurrency, in physical commodity, the process of 'mining' is subject to availability of the underlying asset. Farmers are like miners and they will have to announce the production of the commodity. This 'announcement' would trigger the match-making process where registered 'buyers' will be matched.
However, just like you I have my doubts on it being fully "chain code" based. Reason for that being the underlying commodity - coffee - is also simultaneously being traded on commodity exchanges and if the "chain code" prices drifts too far from the exchange prices then the marketplace ecosystem would revert back to traditional channels outside of blockchain.
So in a way the commodity exchange is still the "trusted provider" of the pricing match (albeit indirectly).
Like you, I am of the opinion that this implementation creates more questions than solutions.
This video tries to explain some details -> Journey of Coffee on Blockchain
In my opinion, it might works in other way round:
When GROWER-A submits a transaction that they have a new batch of beans ready for shipment, then it is added to a list and it will be triggered when a BUYER-B wants to buy some quantity of bean.
Suppose a BUYER-B wants to buy a new batch of beans(some quantity), then it will trigger the API to invoke a chaincode method to transfer the beans from GROWER-A to BUYER-B.
So from this it can be concluded that, there might be a chance of two chain, chain A for GROWER which will be add on block when GROWER-A wants to submit a bean and remove one block when BUYER-B wants to buy it.
And chain B will be for buyer which will work alternatively.
This video explains the example in detail. Hope it answers some of your questions.
Per this explainer video -
1) Buyer brews a cup of coffee, and hence its stock of coffee beans goes down
2) Buyer buys beans to restock
3) Grower ships beans to the buyer
4) Once the Buyer confirms the receipt of the shipment, grower gets paid
The video also explains:
Coffee beans prices may differ based upon the quality and demand. Quality may be determined by popularity or by a certifying body
All the transactions are governed by Smart Contracts. Each participant in this, say Coffee Business, network - the buyer, the grower, the payment company, the bank, the certifying body, the shipping company, even coffee making machines (read, IoT) - agrees to abide by relevant contract(s)
As far as I know, IBM's Blockchain solution is for Enterprises, and not general public, like Bitcoin Exchange. So, all the enterprises become part of that same network.
I wish to enquire if there are maximum no. of participants, assets, transaction that hyperledger can support?
Also, is there rollback (ACID compliant, example) if the submission of a transaction fails?
Thank you.
Nathan Aw
I wish to enquire if there are maximum no. of participants, assets, transaction that hyperledger can support?
Of course there will be limits. But they are, for practical purposes, high enough to allow serious work to be done. Participants can take several forms:
organizations with a separate identity and potentially with their own CA, MSP, orders, endorsers, and committers in any combination
roles in chaincodes
identities with a specific role in an organization
The most limited will be organizations and peers etc, but a consortium can still be big enough to accommodate more than a small number of these to my knowledge. Roles and identities are dependent on your needs and the design of your smart contracts. Unless you are stress testing, how many of each do you really need? (Identities will be of course be largest in number, but the system is designed with that in mind, again to my knowledge).
So my point here is that the limits should be adequate for most practical purposes.
Also, is there rollback (ACID compliant, example) if the submission of a transaction fails?
The whole point of a blockchain is to provide a transparent, distributed ledger with perfect consistency at all times. So the answer is yes.
Note, though, that roll-back simply means that at transaction succeeds or fails and that all copies of the ledger will have the identical result. If the transaction fails, then none of its changes will appear in the ledger.
Transaction failure modes:
Fail during endorsement happens when the chaincode chooses to fail the transaction for violation of business rules or for internal errors.
Fail during commit happens when two transactions execute in parallel (for practical purposes that is -- they could execute too close together and get the same effect) and (a) touch the same keys, and (b) end up in the same block. In this case, the endorsers happily create the read / write sets for both, but the committers find that the second transaction is reading an invalid version of a key that was updated by an earlier transaction in the same block. The read / write set is never applied, thus providing the roll-back.
The solution to consistent failures during commit is to add flow control into the application. You cannot solve that in the chaincode.
There is no limit in the number of participants that can take part in an Hyperledger Blockchain. However, they will be private Blockchains, so everybody wouldn't take part on it.
About the fail of the submission of a transaction, it depends on what you mean with it. A transaction could fail when it is send by a user. However, once a transaction starts its trip, it will terminate.
Once a Peer sends a transaction, it waits to get an answer. It could be successfull or not, but it needs an answer. If I were you, I'd read about the transaction flow of a transaction in Hyperledger Fabric. Or about the Basic workflow of transaction endorsement
I have two queries related to ethereum. I am trying to do a proof of concept that required multiple users to have access to a blockchain node.
(1). Can I have like a million user accounts on Ethereum's Node. Or does ethereum has restriction in the number of accounts.
(2). I want to have user level restrictions in place. So, for instance there are two customers transacting with few other customers. Each of the customers should see his own transaction. Simply said.
For instance, both the below transactions happen on a blockchain node.
A->B 5 USD
C->D 10 USD
A and B should only see 5 USD transaction on their UI.
C and D should only see 10 USD transaction on their UI.
Bank should see both the transactions.
Is the above possible on ethereum or do we have some restrictions on above.
Responses are appreciated
In the public Ethereum network:
Q1: You can have data about as many accounts as you require. Someone pays the gas cost of all state commits. This data is on all verifier nodes, so generally-speaking, everyone has a copy.
Q2: It's possible to design smart contracts to enforce these sorts of rules, but one should keep in mind that all information on the chain is visible to a determined adversary even if the contract(s) is designed to restrict access. Since all nodes verify all transactions, it follows that all data is visible to all nodes.
There are some variants of Ethereum that apply different approaches to verification and confidentiality.
Different between various blockchain protocols
Hope it helps.
Yes ,You can do this by writing some logic which will restrict customer to see some certain transaction and other stuff. this can only be done in front end application. Ethereum is permission-less block chain network which means that every one in network can see all the data. From front end we can stop users but keep in mind still they can view all the transaction or data from Ethereum client console like GETH.
Note:it is not best use case for Ethereum you can use fabric for it.