This proposal evolved from thinking about deploy gossip protocol and made under assumption that all validators in a shard are obliged to provide the same SLA for shard users, and users do not differentiate validators. Feel free to question this statement if not agree.
Apologies for not very fell formed idea, but I publish it to start a discussion. Any objections, best practices etc are highly appreciated.
What are the requirements for deploy gossiping/propagation and why we need it?
Maximal possible decentralisation.
Block finalisation depends on how many blocks of other validators are proposed on top of it. So when all blocks creation time is about the same - finalisation time is predictable. When one node hoard deploys - it introduce delay because time to create block will be big. So equal distribution of deploys across validators in a shard is good.
We need (ideally) not have two conflicting deploys on two different validators at a time. In general this is about making less conflicting blocks. So we need some analytics when distributing deploys across the validator set. This is future task when we can detect conflicting deploys at compile time. But the reason here is that we need that analytics before assigning deploy to particular validator. After some discussions it was decided that with block merging implemented there will be no such thing as the conflicting blocks, conflicts will be on per deploy basis. Two blocks always can be merged, and only one of conflicting deploys will go through. Other deploys which do not cause conflicts won't be affected.
Short term goal might be to make some deploy go through as fast as it possible, by sending deploy to some validator that is going to issue block soon. This is an example of analytics function, and there might be many of them aiming different optimisations.
General point - each shard is a decentralised computer, so deployer submit a code to a shard, not to particular validator, it should be abstracted from that. Shard is the entity that provides consistent Term of Service, cost policy, etc.
Design
So the following is suggested:
Currently deployer have to query for block height to supply validAfterBlockNumber, so we have a “pre-deploy“ stage where deployer have to get some information from the network before supplying the actual deploy.
Let's call this stage Reception and introduce target validator (lets call it ExecutiveValidator) switch here. Let's call node that does reception Porter. Later some logic that will pass deploy not to just some random validator but to the most suitable one can be added, e.g. to produce less conflicting blocks.
A piece of data that is required to do a deploy introduced - a Parole, an offer of ExecutiveValidator to receive deploy with particular deploy signature. Parole = {block-height, word}. Word is the passphrase that deployer should supply to validator to get the deploy accepted. Later we can add more fields to Parole to enable cryptographic proofs, eliminating duplicates and so on. But for now let's KISS.
Deployer should issue a ParoleRequest to any shard peer (playing here role of Porter) before making deploy.
When receiving ParoleRequest, Porter looks into the most recent bonds map, pick validator, forwards ParoleRequest to potential ExecutiveValidator.
ExecutiveValidator responds with the Parole. PorterValidator forwards Parole to deployer.
Deployer sends deploy, providing Parole to ExecutiveValidator.
Feasibility
Initial implementation in trusted environment should be pretty straight forward. To make it robust to malicious actors will take unknown amount of work. So the question is - is this feasible strategy to let any peer act as Porter? If we restrict only validators to be Porters? Is there any reasons why it is not feasible so we can kill it fast?
Motivation
This proposal evolved from thinking about deploy gossip protocol and made under assumption that all validators in a shard are obliged to provide the same SLA for shard users, and users do not differentiate validators. Feel free to question this statement if not agree.
Apologies for not very fell formed idea, but I publish it to start a discussion. Any objections, best practices etc are highly appreciated.
What are the requirements for deploy gossiping/propagation and why we need it?
Maximal possible decentralisation.
Block finalisation depends on how many blocks of other validators are proposed on top of it. So when all blocks creation time is about the same - finalisation time is predictable. When one node hoard deploys - it introduce delay because time to create block will be big. So equal distribution of deploys across validators in a shard is good.
We need (ideally) not have two conflicting deploys on two different validators at a time. In general this is about making less conflicting blocks. So we need some analytics when distributing deploys across the validator set. This is future task when we can detect conflicting deploys at compile time. But the reason here is that we need that analytics before assigning deploy to particular validator.After some discussions it was decided that with block merging implemented there will be no such thing as theconflicting blocks, conflicts will be on per deploy basis. Two blocks always can be merged, and only one of conflicting deploys will go through. Other deploys which do not cause conflicts won't be affected.Short term goal might be to make some deploy go through as fast as it possible, by sending deploy to some validator that is going to issue block soon. This is an example of analytics function, and there might be many of them aiming different optimisations.
General point - each shard is a decentralised computer, so deployer submit a code to a shard, not to particular validator, it should be abstracted from that. Shard is the entity that provides consistent Term of Service, cost policy, etc.
Design
So the following is suggested:
Currently deployer have to query for block height to supply validAfterBlockNumber, so we have a “pre-deploy“ stage where deployer have to get some information from the network before supplying the actual deploy.
Let's call this stage
Receptionand introduce target validator (lets call itExecutiveValidator) switch here. Let's call node that does receptionPorter. Later some logic that will pass deploy not to just some random validator but to the most suitable one can be added, e.g. to produce less conflicting blocks.A piece of data that is required to do a deploy introduced - a
Parole, an offer ofExecutiveValidatorto receive deploy with particular deploy signature.Parole= {block-height, word}. Word is the passphrase that deployer should supply to validator to get the deploy accepted. Later we can add more fields toParoleto enable cryptographic proofs, eliminating duplicates and so on. But for now let's KISS.Deployer should issue a
ParoleRequestto any shard peer (playing here role ofPorter) before making deploy.When receiving
ParoleRequest,Porterlooks into the most recent bonds map, pick validator, forwards ParoleRequest to potentialExecutiveValidator.ExecutiveValidatorresponds with theParole.PorterValidatorforwardsParoleto deployer.Deployer sends deploy, providing
ParoletoExecutiveValidator.Feasibility
Initial implementation in trusted environment should be pretty straight forward. To make it robust to malicious actors will take unknown amount of work. So the question is - is this feasible strategy to let any peer act as
Porter? If we restrict only validators to bePorters? Is there any reasons why it is not feasible so we can kill it fast?