dymensionxyz / dymension Goto Github PK
View Code? Open in Web Editor NEWDymension Hub
Home Page: https://dymension.xyz
License: Other
Dymension Hub
Home Page: https://dymension.xyz
License: Other
When a sequencer is attached to a rollapp it can start to serve the rollapp chain and publish state updates. Create a UpdateState transaction.
Block description object:
The following fields are required for updating a state:
StateInfo object:
Remove any dependencies related to Vue in the repo
On new rollapp creation, the first block is expected to be at a height of zero.
Zero is an invalid startHeight in dymint (and in terndermint also).
Change it to 1.
change also the stateIndex to start from 1 so the value will be equal to the number of updates.
For more details see Update rollapp state
On EndBlocker()
state updates that finished the dispute period are finalized.
We need to emit an event so light-clients (and relayer) could know when the state was finalized.
In order to support additional statuses of a state update, create a new event of StatusChange with the following attributes
RollappId - is the rollapp identifier
StartHeight - is the block height of the first block in the batch
NumBlocks - is the number of blocks included in this batch update
Status - is the status of the state update
StateInfoIndex - is an index for indexing to a specific state info
dymint sends UpdateState and checks that the state was actually updated.
The easiest and most efficient way to do it is to listen to an event when the state is updated on the chain.
On successful state update emit the following event:
message EventStateUpdate {
// rollappId is the rollapp that was updated
// The rollappId follows the same standard as cosmos chain_id
string rollappId = 1 [(gogoproto.moretags) = "yaml:"rollapp_id""];
// latestStateInfoIndex is a sequential increasing number, updating on each
// state update used for indexing to a specific state info
uint64 index = 2 [(gogoproto.moretags) = "yaml:"index""];
// startHeight is the block height of the first block in the batch
uint64 startHeight = 3 [(gogoproto.moretags) = "yaml:"start_height""];
// numBlocks is the number of blocks included in this batch update
uint64 numBlocks = 4 [(gogoproto.moretags) = "yaml:"num_blocks""];
// DAPath is the description of the location on the DA layer
string DAPath = 5 [(gogoproto.moretags) = "yaml:"DAPath""];
}
CreateSequencer currently does nothing but create a sequencer object and provide quires.
In dYmension, a rollapp object contains all the configuration and definitions for a rollapp chain. Users can create a rollapp and later on add sequencers to serve it.
The following fields are required for creating a rollapp:
1. User can send a transaction for creating a new rollapp
1. Retrieving a rollapp object by rollappId
2. Retrieving a list of all rollapp objects
Currently, we want to control who can deploy a rollapp. For the testnet, only the flagship rollapp will be deployed. Create a whitelist of the accounts that are allowed to deploy.
On CreateRollapp, check that the sender is one of the accounts that are whitelisted. If the list is empty, everyone can create a rollapp.
Create a module parameter for holding the list.
A sequencer is like a full node serving a rollapp chain. A sequencer is attached only to one rollapp chain (rollappId) and identified by SequencerAddress. Contrary to a validator full nodes, the address that is used is a regular account address and not ValAddress nor ConsAddress. The sequencer must use its' SequencerAddress for interacting with dYmension.
Sequencer description object:
The following fields are required for creating a sequencer:
1. User can send a transaction for creating a new sequencer
1. Retrieving a list of all sequencers
2. Retrieving a sequencer object by sequencerAddress
3. Retrieving a list of all sequencers by rollappId
When creating a sequencer it is attached to a specific rollapp instance (identified by rollappID), and this rollapp should be already existing. A rollapp also has a limit of maximum sequencers that could be attached and might have a list of permissioned sequencers. Both needed to be checked when creating a new sequencer.
1. Retrieve rollapp object from the rollapp keeper
- if not exists return ErrUnknownRollappId
2. If PermissionedAddresses list isn't empty:
- check if the sequencer is in the list, if not return ErrSequencerNotPermissioned
3. Check that number of rollapps attached to this rollapp does not exceed MaxSequencers:
- if not(SequencersByRollapp(rollappId)<rollapp.MaxSequencers) return ErrMaxSequencersLimit
1. ErrUnknownRollappId
2. ErrSequencerNotPermissioned
3. ErrMaxSequencersLimit
Only the current active sequencer should be able to submit a state update.
After creating a rollapp and adding sequencers. The first sequencer becomes active, this active sequencer can start publishing state updates. Check the update-state transaction transition.
Check the basic validations as in Update rollapp state
Once sequencer created for a specific rollapp, this sequencer address can't be registered or moved to different rollapp.
It enforce limitations on dev env,
as each time a new rollapp is initialized, it requires to use different settlement account and keyring.
I think at least for now, we should provide the possibiliy to either unregister sequencer, or to allow register same sequencer on different rollapps
TBD
A sequencer could be in many stages, among them: initialized and active. Initialized should be the initial status when the sequencer is created and active is when it is allowed to submit state updates. Currently, only one active sequencer will be supported and that is the first one that was attached to the rollapp.
Create a map between sequencerAddress and the sequencers' operating status.
Currently, a sequencers' operating status will have only two statuses: "PROPOSER" & "INACTIVE"
The setup_local.sh
doesn't build and overwrite the dymd executable.
It means that if we built dymd once on version X,
and now we change the branch to version Y,
the setup_local.sh
as used in the docs will not build the new version
Following cosmos note on the dragonberry security advisory. We must upgrade the cosmos SDK to version>=0.45.9
Upgrade the SDK to v0.45.10
We are using the dymension ibc-go. This upgrade is dependent on dymensionxyz/ibc-go#25
Enable simulation tests
CreateRollapp currently does nothing but create a rollapp object and provide quires.
In a permissioned deployment of RollApps, we are limiting the amount of RollApps are deployed not only the addresses that may deploy a RollApp. For example, one address should only be able to deploy one RollApp.
The example for this is that it hard codes a limit for RollApp deployment based on on-chain governance reducing the trust-assumption that an address will only deploy one RollApp.
In the SetRollapp
function, we should check that the address key has zero RollApp IDs. If it has more than zero than a RollApp has already been deployed.
func (k Keeper) SetRollapp(ctx sdk.Context, rollapp types.Rollapp)
see packet-forward-middleware discussion
Integrate the [packet-forward-middleware module to the dymension hub
Create a test where two dymint clients, rollapp1 & rollapp2, are connected to the hub and transfer tokens from rollapp1 to rollapp2 and the same tokens back from rollapp2 to rollapp1
BlockDescriptor holds two states: StateRoot & IntermediateStatesRoot. Currently, they are strings that are not compatible with dymint. change it to byte array. The array size must be 32 bytes.
Add a check of the array size in UpdateStates' ValidateBasic and update tests as well.
Currently, the sequencers' PubKey is the public key of the sequencers' account on the hub.
The key is provided on MsgCreateSequencer and stored as part of the sequencer.
The PubKey should be the public key of the dymint client that the sequencer is running.
The public key prototype should be tendermint/crypto/keys.proto
To make it more clear, use DymintPubKey as the field name and not PubKey
Queries should follow the following standard:
get-state-info-by-height [rollapp-id] [height]
Merge with show-rollapp-state-info [rollapp-id] [state-index]
by adding flags
latest-finalized-state-info [rollapp-id]
change to show-latest-finalized-state-info
We need it for easier filtering of the active sequencer in dymint.
Removes static folder and docs.go
The IRC is like IBC for rollapps; therefore IRC utilizes the IBC stack using dymint-light-client.
The dymint-light-client doesn't check the validity of the consensus as there is no consensus for rollapps.
The dymension hub is maintaining the rollapp state and finalization. Following ADR-01, a rollapp client state should be updated only when the state is finalized.
Using IBC client-callback allows for validating any client state changes in the application logic.
In each callback, check that the state as reported in the transaction is a finalized state as the settlement layer knows.
If the state is not finalized, return error: ErrNotFinalizedState
Use IBC testing for creating a chain identified as a dymint and another chain as the hub.
Check 02-transactions for finalized state and not-finalized state.
Create script for setup and running of local node of dymension
In dYmension protocol, a state update could be in some statuses. Currently, fraud-proofs are not supported, therefore only the following statuses are supported:
Received - transaction was published on dYmension chain
Finalized - the “Dispute Period” has ended and this state is considered final
Create a status object to provide a state and transition functions:
Create module parameters for DisputeBlockPeriod.
The states of a rollapp are indexed internally by the number of UpdateState transactions.
But there is no easy way to query the latest StateInfo that was finalized.
Create a new query: LatestFinalizedStateInfo
to retrieve this information by rollappId
When the rootCmd "dymd" is run it returns "Stargate CosmosHub App" instead of "Start dYmension app" as it should. There seems to be a difference between our CMD folder in the dymension repo vs. standard Cosmos chains (e.g. Gaia). This could potentially be the cause of this issue.
Gaia structure:
cmd/appd/cmd/root.go
cmd/appd/cmd/root_test.go
cmd/appd/main.go
While our repo has only:
cmd/dymd/main.go
StateIndex is used in 3 places:
The way it is currently used is confusing. The name should tell that it is related to a StateInfo and the usage as a pointer to the latest state should be implied by the store name.
Per rollapp, the settlement stores and index block-batch updates by what is called StateInfoIndex
.
In that way, the updates are indexed by time (the first update at index 1 and so on),
The settlement tracks the last index, but not giving an easy and efficient way to query 'StateInfo' based on rollapp block height.
In the ibc_client_hooks there is a validation process that requires obtaining the 'StateInfo' by rollapp height. Currently, it is done in 'getStateInfo' method which is implemented in the hooks. The logic that is applied there today is inefficient and makes scanning over all the indexes (from the newest to oldest).
We need to make a public query so other clients could access state information by rollapp high.
The algorithm/indexing for retrieving a StateInfo by rollapp height should be efficient.
The following algorithm is searching for the block batch of height 'h'
Eventually there will be multiple testnets (i.e. permissioned RollApp deployment and permissionless). They will live in parallel to let developers to build on the permissionless testnet and prepare a permissioned for launch which will upgrade to a permissionless network.
Recommend setting a genesis parameter that indicates if the network is permissioned and who are the administrators. Setting this parameter to false remove admins and removes permissioned constraints.
Sometimes we need shared definitions and functions that more than one module uses. For example, the message Sequencers
is a list of sequencers' addresses. This type is used both by the rollapp and the sequencer module.
message Sequencers
proto to shareFollowing the verified optimism protocol, the status of a state should change. Currently, the supported status changes are as described here.
Hold a map from FinalizationHeight
to FinalizationQueue
which indicates what stateInfo should be finalized on FinalizationHeight
.
add the StateIndex
to the map where the FinalizationHeight
is current blockHeight+DisputePeriodInBlocks
check if there are states to finalize and change the status them to finalize
In the UpdateState
method the current block height is compared to the one stored in the last state and if they are equal, an error is returned.
the issue is that when it running on simulation mode, the handled block is the previous one so the block-heights-validation is wrong here.
the solution is to remove the block-height validation if the UpdateState
method not running in delivery mode.
Entering DYMD command should return "Start Dymension Hub App"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.