gnulib
commented
6 years ago Assumptions
- Will NOT process individual transactions
- Will only validate transaction signatures, PoW validity, and block/transaction ordering
- Will NOT provide any consensus or data queries
- Will monitor/register for specified network, and maintain configured “depth” of block headers
- Application will “encrypt” any private/sensitive transaction payload that it does not want witness node to be aware of (protocol only requires signatures to be validated, actual transaction is not replayed)
Requirements
- REST API is provided to manage network membership on a witness node
Protocol Specs
- a transaction is signed by all participants of the transaction
- so, for example, both payer and payee sign a payment transaction
- transaction specifies minimum vote (w) to be accepted
- network should have w+ number of witness nodes
- for each transaction in a block, witness node does following:
- validate that transaction has been signed by all participants
- create a new signed +1 vote for each successfully validated transaction
- send the +1 vote to each of the participant of the transaction
- each participant of a transaction, upon receiving at least “w” +1 votes, accepts/finalizes the transaction
Now
- should +1 vote only be sent to transaction participants, or should they be broadcast on network?
- reason: all peer nodes are processing the transaction, not just the transaction participants. Hence, all peer nodes need to receive at least “w” +1 votes before accepting/finalizing the transaction
- benefit: we no longer need to worry about sending the +1 vote to “participant”, we just broadcast and let the vote propagate to all nodes eventually
- drawback: this will create at least “w” factor more messages for each transaction — basically network flooding with +1 votes.
- How to prevent one malicious “participant” from hijacking the network by adding its own “w+” nodes to the network?
- should a witness node also have some kind of “org” id? That still does not prevents malicious participant from creating fake “w” unique org id?
- how about making list of valid org id a network configuration parameter (config param will apply to peer nodes — regardless of wether they are native application peers, or off-the-box peer node)?
- As a side note, with “at-least w +1 votes" protocol, we can get away from PoW consensus. The +1 vote itself is the consensus protocol. This can work in smaller networks, but is not “world” scale (that’s where PoW comes into picture)
- how will we know “w” (count of witness nodes) registered on the network?
- actually “w” is not network state parameter, its a transaction parameter (minimum acceptable endorsements) — hence we do not need to know count of currently registered witness nodes on the network, we only need to know how many endorsements are expected by transaction submitter. “w” is an absolute number, not a fraction
- potentially, higher “w” means higher transaction cost (how about w^2), so more secured transactions pay higher cost of endorsement — but then now we need to start tracking account balances and validate transaction fee payments etc, which adds complexity and cost to the whole protocol (although it would be much faster, since we are not doing any PoW or mining/endorsement award, only doing transaction fee deduction from accounts that have some pre-funded balance)
- A side effect of this protocol is that we cannot have any “value transfer” type transactions — since for those transactions all peers need to be in agreement (not just “w”, when “w” << network size) or else we have double spending problem
- On the flip side, when number of peer nodes in a private network is less than “w” (number of witness nodes subscribed to the network) then we can safely have the "value transfer” transactions
SO, THE REAL STRENGTH OF WITNESS NODE PROTOCOL IS TO PROVIDE STRONG SECURITY TO PRIVATE NETWORKS THAT HAVE SMALL/FEW NUMBER OF PEER NODES!
- TODO: need to evaluate different failure scenarios e.g.:
- node received w-1 votes and then went down, when it comes back up, how will it receive the remaining vote?
- what if there were only w-1 votes ever and that transaction never received w+ votes?
- how about transactions that receive w+ votes but fail validation on peer node?
- how will bootstrap and handshake/sync work for “pending” transactions? (it would probably be related to how remaining votes be received)
- Oh! so an accepted block forward (by a peer) would include all w+ votes for the accepted transactions — thats how a bootstrap handshake/sync can work
So, in general, protocol looks like following:
- a transaction is signed and submitted to a witness node
- witness node validates transaction (no transaction replay, only signature validation) and broadcasts its +1 vote to the network
- a peer node receives a +1 vote for a transaction and records vote count for the transaction
- when peer node has received w+ votes for a transaction, it finalizes transaction (what does this mean?) and broadcasts transaction block (transaction + w+ votes) to the network
- when a peer node receives a new transaction block, it validates and add the block to its Block-DAG
How will a transaction block be finalized?
- its clear, we are not doing any PoW, nor are we using centralized coordinator, hence we’ll need to use Block-DAG (there is no ordering mechanism needed for a block-chain, different peers may be finalizing different transactions at any time, based on timing of receiving the w’th vote for a transaction)
- challenge of Block-DAG is double spending in value transfer type transactions
- handshake/sync also needs to be defined to be able to handle Block-DAG (i.e. no longer can discard an unknown block, will need to start sync to fetch ancestors of that block to complete the missing portion of DAG)
Description
As a developer,
I would like to know API specifications for a witness node to join/leave an existing blockchain network,
so that I can manage blockchain membership for my witness node dynamically.
Acceptance Criteria