Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend getversion RPC response with additional protocol settings #3401

Closed
AnnaShaleva opened this issue Jul 5, 2024 · 5 comments · Fixed by #3443
Closed

Extend getversion RPC response with additional protocol settings #3401

AnnaShaleva opened this issue Jul 5, 2024 · 5 comments · Fixed by #3443
Assignees
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@AnnaShaleva
Copy link
Member

Summary or problem description

Some dApp developers face the necessity to restore blockchain using settings from protocol section of getversion RPC response without additional knowledge about node configuration. I discovered that this section doesn't contain the following protocol settings:

  • MaxBlockSize
  • MaxBlockSystemFee
  • StandbyCommittee
  • SeedList

Without StandByCommittee it's impossible to restore blockchain. Without MaxBlockSystemFee and MaxBlockSize it's impossible to properly verify blocks and/or transactions. Without SeedList it's impossible to sync the network.

I see that there's a need for these settings to be included into getversion response, it would be beneficial for Dora Explorer back-end development.

Do you have any solution you want to propose?
Extend protocol section of getversion RPC response with these protocol parameters. MaxBlockSize, MaxBlockSystemFee and StandbyCommittee are a must-have from my PoW, whereas SeedList is a matter of discussion.

It's easy to implement, but I'd like to collect some more opinions on this topic before the modification. If we agree, then I'll implement it.

Where in the software does this update applies to?

  • RPC (HTTP)
@AnnaShaleva AnnaShaleva added the Discussion Initial issue state - proposed but not yet accepted label Jul 5, 2024
@shargon
Copy link
Member

shargon commented Jul 5, 2024

Some of these values comes from DBFTPlugin, so this will produce a dependency between both plugins

@AnnaShaleva
Copy link
Member Author

Some of these values comes from DBFTPlugin

I forgot about it, NeoGo has everything in a single configuration. Can we live with this dependency? Or another solution may be to move MaxBlockSize and MaxBlockSystemFee settings to the core settings.

@dusmart
Copy link

dusmart commented Jul 9, 2024

If it's from DBFTPlugin's configuration, it means that they won't be essential for validating the block by normal nodes. Which also means that MaxBlockSize and MaxBlockSystemFee are actually not the hard standard for validating the blocks. The CNs can change them at any time at their wills.

Therefore, I'm not sure if it's a good idea to expose those settings to others.

@vncoelho
Copy link
Member

vncoelho commented Jul 9, 2024

I am in favor of living without the dependency for now.

@roman-khimov
Copy link
Contributor

MaxBlockSize and MaxBlockSystemFee can be omitted, but committee/seeds are easy to add and they really open up some additional possibilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants