[WIP]Make chainspec extendable by plugins #7540
Conversation
deffrian
changed the title
| // hex encoded byte array | ||
| string hex = valueString.Trim().RemoveStart('0').RemoveStart('x').TrimEnd(); | ||
| value = Enumerable.Range(0, hex.Length) | ||
| .Where(x => x % 2 == 0) | ||
| .Select(x => Convert.ToByte(hex.Substring(x, 2), 16)) | ||
| .ToArray(); |
There was a problem hiding this comment.
Bytes.FromHexString
AsSpan().Trim() if needed
| value = null; | ||
| return false; | ||
| } | ||
| switch (Type.GetTypeCode(type)) |
There was a problem hiding this comment.
Dont understand what you mean
| private readonly long? _bedrockBlockNumber = parameters.BedrockBlockNumber; | ||
| private readonly ulong? _regolithTimestamp = parameters.RegolithTimestamp; |
There was a problem hiding this comment.
Why do we have to make stuff nullable?
There was a problem hiding this comment.
There might be no value in config, so better to make it nullable imo
| JsonProperty? jsonProperty = _chainSpecParameters[engineName].EnumerateObject().FirstOrDefault(p => | ||
| string.Compare(p.Name, property.Name, StringComparison.InvariantCultureIgnoreCase) == 0); | ||
|
|
||
| if (jsonProperty is null) | ||
| { | ||
| throw new FormatException($"ChainSpec property {property.Name} is not set"); | ||
| } | ||
|
|
||
| object value = ConfigSourceHelper.ParseValue(property.PropertyType, jsonProperty.Value.Value.ToString(), "chainspec", property.Name); | ||
| property.SetValue(instance, value); |
There was a problem hiding this comment.
Can we just use json deserialization here?
There was a problem hiding this comment.
I thought best idea is to do th same way we do in config. Just extending capabilities for chainspec
| private void InitializeInstances() | ||
| { | ||
| Type type = typeof(IChainSpecEngineParameters); | ||
| IEnumerable<Type> types = TypeDiscovery.FindNethermindBasedTypes(type).Where(x => x.IsClass); |
There was a problem hiding this comment.
Do we want auto-discovery or explicit registration?
There was a problem hiding this comment.
In the Transaction type refactoring we've been working with explicit registration. This should make transitioning to a DI approach easier but makes the immediate code harder since you need to register at the appropriate time, a lot of times directly into static fields.
There was a problem hiding this comment.
Same argument, do as in config. But I don't mind both tbh
| { | ||
| Type type = typeof(IChainSpecEngineParameters); | ||
| IEnumerable<Type> types = TypeDiscovery.FindNethermindBasedTypes(type).Where(x => x.IsClass); | ||
| foreach (Type @class in types) |
There was a problem hiding this comment.
Instances should be constructed lazily?
There was a problem hiding this comment.
Construction is done on setup, so performance is not a concern(it takes small amount of time). I prefer to catch any miss-configuration errors at this point.
src/Nethermind/Nethermind.Specs/ChainSpecStyle/IChainSpecEngineParameters.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Specs/ChainSpecStyle/ChainSpecParametersProvider.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Lukasz Rozmej <[email protected]>
Co-authored-by: Lukasz Rozmej <[email protected]>
| IEnumerable<Type> types = TypeDiscovery.FindNethermindBasedTypes(type).Where(x => x.IsClass); | ||
| foreach (Type @class in types) | ||
| { | ||
| string engineName = @class.Name.Remove(@class.Name.Length - EngineParamsSuffix.Length); |
There was a problem hiding this comment.
Could we do the discovery based on implementing IChainSpecEngineParameters rather than class name? Even if we go with the manual registration route we could perform this check.
There was a problem hiding this comment.
Not sure what you mean. It already looks for all inheritors of IChainSpecEngineParameters. I didn't make manual registration because ChainSpec is more similar to IConfig. So I thought we should behave the same way here
src/Nethermind/Nethermind.Specs/ChainSpecStyle/ChainSpecParametersProvider.cs
Outdated
Show resolved
Hide resolved
| private readonly Dictionary<string, JsonElement> _chainSpecParameters = | ||
| new(StringComparer.InvariantCultureIgnoreCase); | ||
|
|
||
| private readonly ConcurrentDictionary<Type, IChainSpecEngineParameters> _instances = new(); |
There was a problem hiding this comment.
Why does this have to be concurrent? We cannot add elements through AllChainSpecParameters and there is no other accessor.
| public interface IChainSpecParametersProvider | ||
| { | ||
| string SealEngineType { get; } | ||
| ICollection<IChainSpecEngineParameters> AllChainSpecParameters { get; } |
There was a problem hiding this comment.
If we don't intend to allow modification (which I think we don't) prefer IEnumerable to ICollection
| { | ||
| ArgumentNullException.ThrowIfNull(RegolithTimestamp); | ||
| ArgumentNullException.ThrowIfNull(BedrockBlockNumber); | ||
| ArgumentNullException.ThrowIfNull(CanyonTimestamp); |
There was a problem hiding this comment.
Some of these fields (like CanyonTimestamp) used to be nullable and still are here, but others have changed (like RegolithTimestamp).
Which fields are actually required and which are not?
…tersProvider.cs Co-authored-by: Lautaro Emanuel <[email protected]>
Co-authored-by: Lukasz Rozmej <[email protected]>
Co-authored-by: Lukasz Rozmej <[email protected]>
…tersProvider.cs Co-authored-by: Lautaro Emanuel <[email protected]>
deffrian
force-pushed
the
refactor/chainspec-v2
branch
from
32cbfa4
to
b6f1a53
Compare
Fixes Closes Resolves #
#6222
Right now our ChainSpec is a mess. This pr tries to fix some issues.
Changes
Adds new interface
IChainSpecEngineParameters. This works similar toIConfig.ReleaseSpeccreation we callIChainSpecEngineParameters.AddTransitions. Plugin devs write implementation of this function if they want to add transitions.ReleaseSpeccreated we callIChainSpecEngineParameters.AdjustReleaseSpec. Plugin devs write implementation of this function if they want to change any parameters in ReleaseSpec.Types of changes
What types of changes does your code introduce?
Testing
Requires testing
If yes, did you write tests?
Notes on testing
Optional. Remove if not applicable.
Documentation
Requires documentation update
If yes, link the PR to the docs update or the issue with the details labeled
docs. Remove if not applicable.Requires explanation in Release Notes
If yes, fill in the details here. Remove if not applicable.
Remarks
Optional. Remove if not applicable.