Switchable Consensus Parameters - Besu - LF Decentralized Trust


    
        
            
                
                                

        


        
            

            






Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
PreferencesOnly necessaryAccept all









LF Decentralized Trust

LF Decentralized Trust

Spaces

Apps
Templates

Create
























Besu




	All content



Shortcuts



	Meetings

Meetings


 This trigger is hidden

	How-to articles

How-to articles


 This trigger is hidden






Content







Results will update as you type.

	Code of Conduct





	Contributing





	Developing and Conventions





	Documentation





	Community





	Governance





	Programs & Grants





	Meetings





	Design Documents




	Ethereum Classic Support





	Feature Proposal Template





	Feature Flags





	RPC Endpoint Service





	Switchable Consensus Parameters





	Bonsai Tries Design Overview





	Refactor EVM into a stand alone library





	SECP256R1 Support





	DRAFT - Pico CLI Plugin Integration





	Besu 2022 Vision





	Modular Besu





	CI/CD Migration





	Change to Besu Defaults - Q1 2024





	CI/CD Tooling and Process





	Bonsai archive feature







	Security





	Audits





	Start Here





	Performance & Stability





	How-to articles





	Incident Reports





	Besu Roadmap & Planning





	How to Contribute



















You‘re viewing this with anonymous access, so some content might be blocked.
Close













Besu

/
Switchable Consensus Parameters












More actions







Switchable Consensus Parameters

	Trent Mohay (Deactivated)



	Danno Ferrin



	Christopher Hare





Owned by Trent Mohay (Deactivated)


Last updated: Dec 05, 2019 by Danno Ferrin












Real World Use Case
A single member of an IBFT Blockchain consortium wishes to leave the group, but wants to maintain their existing data.
Thus - a mechanism must exist which allows the list of validators to be overridden with a hard-coded list at a given block.
Required Changes
The overall goal of this change is that the validators for an IBFT2 network change at a given block - what this means:
	The genesis file must specify block at which the validators are to change, and also who the new validators are	It must  list the new validators, not just the expected extra data, as the new validators are required to know that at block-X they are
responsible for producing a block (this is different to existing behaviour as the genesis file defines the block upon which all work is to be
performed - this change defines the block to be created).


	IBFT business logic must be able to determine the currently active validators from a source other than just  the latest block - i.e. it must somehow
factor in the "validator switch" data specified in the genesis file
	Block Validator rules must be updated to expect the validators in the block to be either as per existing voting, OR as per genesis file content	This will probably  be abstracted behind the VoteTallyCache


	Votes cast prior to the "change Block" will need to be discarded on a change into a custom fork

Items to Consider
Currently, the overarching behaviour of the system is defined by the ProtocolSchedule and the associated ProtocolContext. the validators and votes are (indirectly) contained within the ProtocolContext, of which
only 1 exists for the lifetime of the network.
It is proposed that ConsensusState contained with the ProtocolContext be either:
	Replaceable upon custom block
	Entire ProtocolContext be overwritten upon custom block

Approach
The existing forking process (in the ProtocolSchedule) is to be reused - however, the forks/milestones will be recognised as "transitions" in the genesis file.
Genesis File

{
  "config": {
    "chainId": 4,
    "homesteadBlock": 1,
    "eip150Block": 200,
    "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "eip155Block": 300,
    "eip158Block": 300,
    "byzantiumBlock": 400,
    "transitions" : {
      "250" : {
        "ibft2": {
          "validators": ["0x12345...", "0x09875..."],
        }
      },
      "350": {
        "ibft2": {
          "validators": ["0x12345...", "0x09875..."],
        }
      },
    },
  },
...



During construction of the ProtocolSchedule additional ProtocolSpecs will be added at the "transitions" block numbers, these












, multiple selections available,





Related content
More info

Collapse
Modular Consensus
Modular Consensus

Besu



More like this






Reworking HL Iroha Consensus API
Reworking HL Iroha Consensus API

Hyperledger Mentorship Program



More like this






Promote Iroha Runtime Validator into Iroha Runtime Executor
Promote Iroha Runtime Validator into Iroha Runtime Executor

Hyperledger Iroha



More like this






Iroha configuration changing
Iroha configuration changing

Hyperledger Iroha



More like this






Modular Besu
Modular Besu

Besu



More like this






Change View Drawback in Sumeragi
Change View Drawback in Sumeragi

Hyperledger Iroha



More like this

































































        

    


    {"serverDuration": 15, "requestCorrelationId": "5cb70b20d6024911839c953ac2776ac2"}