Epoch orchestration layer#427
Conversation
| // Copyright (C) 2019-2025, Ava Labs, Inc. All rights reserved. | ||
| // See the file LICENSE for licensing terms. | ||
|
|
||
| package simplex |
There was a problem hiding this comment.
should the orchastration be in its own package?
There was a problem hiding this comment.
I think it makes sense to put this in the top most package, to make it clear that it is the entry point to simplex.
| // Parameter config | ||
| Epoch: epochNum, | ||
| ReplicationEnabled: true, | ||
| StartTime: time.Now(), |
There was a problem hiding this comment.
should the orchestration layer have its own time field? i don't see where we forward/call advanceTime
| MaxProposalWait: i.Config.MaxProposalWait, | ||
| MaxRebroadcastWait: i.Config.MaxRebroadcastWait, |
There was a problem hiding this comment.
i think we should change in a seperate pr these to be consistent with avalanche go
MaxNetworkDelay time.Duration `json:"maxNetworkDelay" yaml:"maxNetworkDelay"`
MaxRebroadcastWait time.Duration `json:"maxRebroadcastWait" yaml:"maxRebroadcastWait"`| ) | ||
|
|
||
|
|
||
| type Config struct { |
There was a problem hiding this comment.
maybe this type of structure is more organized? this way we can see exactly what is used for the MSM vs epoch vs shared
type Config struct {
// Shared by both the metadata state machine and the epoch.
Common CommonConfig
// Used only to build the metadata state machine.
MSM MSMConfig
// Used only to build the simplex epoch.
Epoch EpochParams
}
type CommonConfig struct {
Logger common.Logger
Signer common.Signer
SignatureAggregatorCreator common.SignatureAggregatorCreator
VM VM
}
type MSMConfig struct {
GenesisValidatorSet metadata.NodeBLSMappings
LastNonSimplexInnerBlock metadata.VMBlock
GetPChainHeightForProposing func() uint64
GetPChainHeightForVerifying func() uint64
ComputeICMEpoch metadata.ICMEpochTransition
}
type EpochParams struct {
ID common.NodeID
Sender Sender
Storage Storage
QCDeserializer common.QCDeserializer
BlockDeserializer common.BlockDeserializer
Verifier common.SignatureVerifier
MaxProposalWait time.Duration
MaxRoundWindow uint64
MaxRebroadcastWait time.Duration
FinalizeRebroadcastTimeout time.Duration
MaxWALSize int
WALCreator wal.Creator
WALs []wal.DeletableWAL
}There was a problem hiding this comment.
this could also help with the organization we talked about at Monday's consensus sync. The caller can see which interfaces it needs to implement and which purposes
| PChainProgressListener metadata.PChainProgressListener | ||
| // LastNonSimplexBlockPChainHeight is the P-chain height of the last block built by a non-Simplex proposer. | ||
| // It is used to determine the validator set of the first ever Simplex h. | ||
| LastNonSimplexBlockPChainHeight uint64 |
There was a problem hiding this comment.
dont see where this is uesd
|
|
||
| ComputeICMEpoch metadata.ICMEpochTransition | ||
| // PChainProgressListener listens for changes in the P-chain height to trigger block building or h transitions. | ||
| PChainProgressListener metadata.PChainProgressListener |
There was a problem hiding this comment.
same, this isn't used anywhere
|
|
||
| func (e *EpochAwareStorage) Index(ctx context.Context, block common.VerifiedBlock, certificate common.Finalization) error { | ||
| if block.BlockHeader().Epoch < e.Epoch { | ||
| // This is a Telock from a previous h, so we ignore it and do not index it. |
There was a problem hiding this comment.
how does this mean the block is a telock? don't telocks have the same epoch as the sealing block?
There was a problem hiding this comment.
this is a Telock from the previous epoch. We may collect a finalization on a Telock and then we first index the sealing block and then the Telocks. Once we index the sealing block, we increment our epoch, right?
We don't want to index the Telocks too, so this is a safeguard against that.
yacovm
force-pushed
the
orchestration
branch
6 times, most recently
from
1779bd4 to
e01b21c
Compare
2 participants
No description provided.