MPC involves running calculations on numbers, perhaps from different parties, and sharing the result without anyone seeing the underlying data. Even the person operating the computer cannot access the information
How is this possible on blockchains like ethereum/corda/hyperledger etc?
Corda is a permissioned blockchain platform, which focuses on Peer to Peer communication. It is direct, private, and secured.
If there is any multiparty computation happening with in a Corda network, it will be happened only among participating parties.
It will happen strictly according to the Corda contract code, which
is developed by the pre-agreed business rules.
Every transaction will collect digital signatures from the participating parties, and distributed the transaction to these participating parties when the transaction is done.
Please see more information at: https://docs.corda.net/docs/corda-os/4.4/key-concepts-ecosystem.html
Related
I'm a newbie, currently interested in data security & integrity.
I'm quite new to blockchain and distributed system theories, and suffering from some unclear doubts/questions on the fault-tolerant consensus.
May I ask for your kind advice on my dull thoughts regarding on the blockchain's true objective?
It would be a great help for me to step forward on understading better concept of consensus.
Here's the summary of what I understand (please correct me if I'm wrong)
In a synchronous network model, it is assumed that one can guarantee the message being delivered within a certain amount of time.
In an asynchronous network model, there is no certain guarantee on the message delivery.
In a design perspective, it is easier & more efficient to design a system based on the synchronous model.
Even the quorum size requirement can be reduced - synchronous model needs only f+1 votes while asynchronous model needs 2f+1 votes on the consensus.
(This is because that the synchronous model can eliminate the possiblity of message dropout (up to f), while the async model needs to consider both message dropout & possibly malicious messages.)
But in a distributed system based on multiple nodes, it is normally impossible to guarantee the message delivery since there is no central manager who can monitor all nodes whether each receives the message or not.
That is why most of the blockchain-oriented distributed ledgers (non-currency) are based on the asynchronous consensus schemes such as PBFT (Castro, Liskov 99).
In a private blockchain scenario, I believe that the main & final purpose of the consensus is to let all nodes hold a chain of blocks, where each block has a certain amount of agreements (i.e. more than f signatures).
So, based on the facts above, I got curious whether the fault-tolerance model only stands for the standard "client-server" environment.
What happens if we give up the client-server model, and let the client supersede peers' broadcast communications? (For a scenario where the client has enough computation power but is just short on storage, so it wants to manage multiple (but few, e.g. 3) replicas to store data via transactions)
To be more specific with a simple example (an authenticated environment with PKI):
Each replica only performs a "block creation (+signing)" and "block finalization (verifying signatures)" logic, and there may exist some malicious replicas (up to f) which try to spread different outputs, which is not originated from the client's transaction.
Let the client (a "data owner/manager" would be a more suitable term now...) visit all replicas, and it handles each replica as below:
Enforce that all replicas work as a synchronized state machine; assure all 3 replicas are synced up (check the latest block of each, and supplement the lagged ones)
Sets a callback (with a timeout) for each replica to guarantee the message delivery
Send a transaction to all replicas, and receive the block (with a signature) generated from the corresponding transaction (assume that the block contains only one transaction)
If more than f signatures (from replicas) for the same block message are collected, deliver the collected signatures to all replicas and order them to finalize the block.
If we do as above, instead of replicas making consensus on their own (i.e. no view-changes), can we still say that the system suffices a BFT model?
It seems that byzantine replicas cannot breach safety, since the client (and honest replicas) will only order/accept block finalization when the block comes with more than f signatures.
The concern is the liveness - can we say that the liveness still holds, since the system can continue (not a client-server model anymore, but the "system" goes on) because the client will ignore the faulty replica response and order honest replicas to finalize?
This curiosity is just stuck in my head, and it's blocking me from clearly understanding why the private blockchain systems need asynchronous consensus process among peers themselves.
(since they already trust the client transactions, and participants are designated by PKI & signatures)
Could anyone be kind and inform that whether my dominant-client example can still suffice the BFT, or something would go wrong?
Thank you so much!
In case of a consortium of banks in a Corda network consisting of one notary, could you please tell me who will be responsible for running the notary? It is clear that a notary is a network service, so can any bank run the notary as and when it wishes to, to check for double spends or is there one "main" bank/node that takes charge to trigger the notary service. Thank you.
It's completely up to the network operator. The network can have anything from a single one-node validating notary to hundreds of pooled non-validating notaries.
You mention bank nodes joining and leaving the notary service at will. This is a property of Proof of Work consensus algorithms (miners can come and go as they please without undermining the consensus result), but it's not a property of consensus algorithms in general. If you wanted to adopt this mode, you'd have to use a suitable consensus algorithm for your notary pool. In general, therefore, you'd generally have nodes contributing to the notary pool full-time.
Depending on your use-case, it may also be preferable for paid third-parties to provide the notary pool, rather than having the banks that are transacting also provide the notarisation service.
Correct me if I am wrong, or confirm, is consensus synchronizing history between peers?
Each peer stores all transactions history?
Each peer is running on separated machines or all peers are running on same machine(in docker for example) ?
Simply the consensus or (total-order broadcast, atomic broadcast) done between peers are on same channel.
Ordering service provides a shared communication channel to clients and peers, offering a broadcast service for messages containing transactions. Clients connect to the channel and may broadcast messages on the channel which are then delivered to all peers.
The channel supports atomic delivery of all messages, that is, message communication with total-order delivery and (implementation specific) reliability. In other words, the channel outputs the same messages to all connected peers and outputs them to all peers in the same logical order. This atomic communication guarantee is also called total-order broadcast, atomic broadcast, or consensus in the context of distributed systems. The communicated messages are the candidate transactions for inclusion in the blockchain state.
Consensus is the process of multiple peers determining if their records of transactions match. With Hyperledger Fabric version 0.6, all of the blocks on the ledger will match across peers if the peers are in consensus. In this version, each validating peer does store all transactions.
Hyperledger Fabric version 1.0 which is under development should make it possible for a subset of participants in a blockchain network to process certain transactions. Information on the future consensus architecture has more details.
The peers usually run in multiple Docker containers that are owned by one entity when using Hyperledger Fabric version 0.6. With upcoming Hyperledger Fabric version 1.0 it should be possible for one entity to start a blockchain network and then invite other parties (such as other companies) to join. In this case, peers would be distributed across multiple entities.
In Bitcoin blockchain a node/peer will order transactions, create a block, does the PoW and "announces" this block to the other miners.
Once the other miners agree (by hashing the block+nounce+etc...) that the block is valid it is part of the blockchain.
But in Hyperledger (as far as I understood) the VPs don't do mining (and hence don't spread the mined block). So how does the individual VPs order them so that all VPs have the same ordered transactions of blocks?
For the Fabric implementation the goal is to have (link):
Consensus is a method for validating the order of network requests, or
transactions (deploy and invoke), on a blockchain network. The correct
ordering of transactions is critical, because many types of network
transactions have a dependency on one or more prior transactions
(account debits often have a dependency on prior credits, for
example). On a blockchain network, there is no single authority that
determines the transaction order; instead, each blockchain node (or
peer) has an equal say in establishing the order, by implementing the
network consensus protocol. Consensus, therefore, ensures that a
quorum of nodes agree on the order in which transactions are appended
to the shared ledger. By resolving any discrepancies in the proposed
transaction order, consensus guarantees that all network nodes are
operating on an identical blockchain. In other words, consensus
guarantees the integrity and consistency of blockchain network
transactions.
Nevertheless in current version there is a leader (one of validation peers) who is responsible for ordering transactions before they are executed by other peers.
In next Fabric’s version this behavior can be changed (Next Consensus Architecture Proposal):
…
A peer communicates with the consensus service and maintain the
blockchain state and the ledger. Such peers receive ordered state
updates from the consensus service and apply them to the locally held
state
…
Peers are clients of the consensus service, to which the consensus
service provides a shared communication channel offering a broadcast
service for messages containing transactions. Peers connect to the
channel and may send and receive messages on the channel. The channel
supports atomic delivery of all messages, that is, message
communication with total-order delivery and (implementation specific)
reliability. In other words, the channel outputs the same messages to
all connected peers and outputs them to all peers in the same logical
order. This atomic communication guarantee is also called total-order
broadcast, atomic broadcast, or consensus in the context of
distributed systems. The communicated messages are the candidate
transactions for inclusion in the blockchain state.
Every description on the Message Bus architecture seems to describe a centralised intermediary for routing messages:
Each application has a single connection to the message bus instead
of multiple dedicated connections to each of the other applications.
http://msdn.microsoft.com/en-us/library/ff647328.aspx
Structure the connecting middleware between these applications as a
Message Bus that enables them to work together using messaging.
http://www.eaipatterns.com/MessageBus.html
Service Bus is messaging infrastructure that sits between applications
allowing them to exchange messages in a loosely coupled way for
improved scale and resiliency.
http://www.windowsazure.com/en-us/home/features/messaging/
The descriptions seem identical to the Message Broker architecture; leading me to believe the following:
The term 'Message Bus' is effectively the same as 'MoM' - a generic term for referring to a messaging infrastructure without explicitly mentioning a topology. I.e. Message Broker is a type of Message Bus.
This seems like a controversial topic, and whilst there's a few similar questions on SO, none have (IMO) definitive answers.
P.s. I am aware that Enterprise Service Bus is entirely different, and is effectively a 'feature rich' MoM.
You are right, this area of terminology is very messy and there are no definitive answer, but this is my view from my professional life:
The first thing is to do is to think about this in different levels of abstractions - architectural concepts vs products.
A message bus (http://www.eaipatterns.com/MessageBus.html) is often referd to a as an architectural princip to decouple applications often together with canonical data formats (http://www.eaipatterns.com/CanonicalDataModel.html), much regardless of technology. Often implemented using MoM products.
A MoM typically refers to a family of middleware products that implements asynchronous message passing. Often built supporting standards such as JMS and AMQP (typically WebSphere MQ, ActiveMQ, Azure messaging, hornetQ, RabbitMQ, etc.etc.).
A message broker is often a MoM, and both terms are used for the same messaging product. There might be confusion here, since the main ESB product of IBM is called WebSphere Message Broker while it rather an ESB used side by side with the MoM product - WebSphere MQ. Usually most MoM call themselves brokers, such as RabbitMQ, ActiveMQ, QPid etc.
Hope this did not cause more confusion :)
The differences are mainly different vendors trying to differentiate themselves in the Market and increase their mind-share. Since vendors typically defined their own terms, there will usually be a slight differences in what each vendor means by the terms they use.
However in general they are the same class or type of system. They organise and manage the transport, queueing and persistence (storage) of messages from one software service to another, beyond that, you need to be looking at vendors specific feature lists for their product.
WebSphere Message Broker belongs to the ESB layer of an SOA and it is also MOM. WebSphere MQ is also MOM. I think a lot of the confusion is around abstract architecture concepts and actual software products. SOA and ESB are abstract concepts. The whole enterprise architecture industry IBM, Microsoft, Oracle, TIBCO etc. are always vying for market share. Software companies often pretend they invented something new and better in order to get attention from their customers. They make a lot of wild promises about their products when in reality they create a whole new set of expensive problems (e.g. XML transformations cause serious performance and security issues). Because it is corporate greed driven and "get to market fast" there is always an abundance of confusion and IT problems and much stress for IT workers.