blockworks-foundation
/
solana-improvement-documents
mirror of https://github.com/blockworks-foundation/solana-improvement-documents.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

solving lint issues

This commit is contained in:
Godmode Galactus 2023-04-15 22:39:08 +02:00
parent 0729165631
commit 62f631f4ea
No known key found for this signature in database
GPG Key ID: A04142C71ABB0DEA
1 changed files with 51 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
proposals/0047-last-hard-fork-syscall.md
View File

@ -11,35 +11,40 @@ created: 2023-04-15
## Summary
Create a new sysvar `SysvarLastHardFork1111111111111111111111111`, which can be used to
get the last hard fork slot.
Create a new sysvar `SysvarLastHardFork1111111111111111111111111`, which can
be used to get the last hard fork slot.
## Motivation
In Solana, when the cluster cannot reach consensus, it is restarted using `ledger-tool`
with a hard fork on a slot. A hard fork is usually done on an optimistically confirmed slot which
was voted on and accepted by 50% of the cluster but still was unable to get a supermajority.
The cluster is then restarted from the hard fork slot, and all participating nodes need to restart
their validator specifying the hard fork slot. Once all nodes participating in the restart effort on
the hard fork exceed 80% of the total stakes, the restart is successful, and the cluster continues
from the hard fork slot. So hard fork is a tool to intentionally fork off the nodes not
participating in the restart effort. After successfully restarting the network the hard fork slot
is stored in a variable called `hard_forks` in bank.
In Solana, when the cluster cannot reach consensus, it is restarted using
`ledger-tool` with a hard fork on a slot. A hard fork is usually done on an
optimistically confirmed slot which was voted on and accepted by 50% of the
cluster but still was unable to get a supermajority. The cluster is then
restarted from the hard fork slot, and all participating nodes need to restart
their validator specifying the hard fork slot. Once all nodes participating in
the restart effort on the hard fork exceed 80% of the total stakes, the restart
is successful, and the cluster continues from the hard fork slot. So hard fork
is a tool to intentionally fork off the nodes not participating in the restart
effort. After successfully restarting the network the hard fork slot is stored
in a variable called `hard_forks` in bank.
Dapp developers may find it useful to know that a hard fork has recently occurred. This
information can help them prevent arbitrage and liquidation caused by outdated oracle price account
states. However, the cluster's restart process takes several hours; in that time, the world
can change, causing asset prices to fluctuate. As the cluster updates the state of all accounts,
malicious actors could take advantage of the delay by conducting trades using outdated prices,
anticipating that they will soon catch up to the actual prices of real-world assets. Knowing that
hard fork has been done recently, dapps can manage these cases more appropriately.
Dapp developers may find it useful to know that a hard fork has recently
occurred. This information can help them prevent arbitrage and liquidation
caused by outdated oracle price account states. However, the cluster's restart
process takes several hours; in that time, the world can change, causing asset
prices to fluctuate. As the cluster updates the state of all accounts,
malicious actors could take advantage of the delay by conducting trades using
outdated prices, anticipating that they will soon catch up to the actual
prices of real-world assets. Knowing that hard fork has been done recently,
dapps can manage these cases more appropriately.
## Alternatives Considered
No alternate considerations; we need to have the value of last hard fork slot while executing
the dapp to correctly treat this case. We cannot have an account because then it should be updated
just after the restart is successful, which will add complexity. The best way is to create
a new sysvar to get this information during execution of transaction.
No alternate considerations; we need to have the value of last hard fork slot
while executing the dapp to correctly treat this case. We cannot have an
account because then it should be updated just after the restart is successful,
which will add complexity. The best way is to create a new sysvar to get this
information during execution of transaction.
## Detailed Design
@ -48,7 +53,8 @@ a new sysvar to get this information during execution of transaction.
Addition of a new file `last_hard_fork.rs` at following location:
`monorepo/sdk/program/src/sysvar` to implement the new sysvar.
We should also implement a new structure to store the last hard fork data similar to:
We should also implement a new structure to store the last hard fork data
similar to:
``` rust
#[repr(C)]
@ -63,7 +69,8 @@ pub struct LastHardFork {
``` rust
crate::declare_sysvar_id!("SysvarLastHardFork1111111111111111111111111", LastHardFork);
crate::declare_sysvar_id!("SysvarLastHardFork1111111111111111111111111",
LastHardFork);
impl Sysvar for LastHardFork {
impl_sysvar_get!(sol_get_last_hard_fork_sysvar);
@ -73,18 +80,22 @@ impl Sysvar for LastHardFork {
### Loading of sysvar during banking stage
The hardfork data is available in the `Bank` structure in the field `hard_forks`. The structure
`HardForks` contains a vector with all the previous hard forks. The vector is also sorted when we
register a slot. So the last element of the vector is usually the last slot at which hard fork was done.
The hardfork data is available in the `Bank` structure in the field
`hard_forks`. The structure `HardForks` contains a vector with all the previous
hard forks. The vector is also sorted when we register a slot. So the last
element of the vector is usually the last slot at which hard fork was done.
We can get the last hard fork slot from the bank and pass it to invoke context structure. We also
have to add a new field to the structure `SysvarCache` so that this data could be efficiently cached.
Now we can easily load the last hard fork data when sysvar is called from invoke context.
We can get the last hard fork slot from the bank and pass it to invoke context
structure. We also have to add a new field to the structure `SysvarCache` so
that this data could be efficiently cached. Now we can easily load the last
hard fork data when sysvar is called from invoke context.
Create a file `monorepo/programs/bpf_loader/src/syscalls/last_hard_fork.rs` to declare syscall class
`SyscallLastHardFork`. This helps to initialize the strucure `LastHardFork` from invoke context and sysvar cache.
Create a file `monorepo/programs/bpf_loader/src/syscalls/last_hard_fork.rs` to
declare syscall class `SyscallLastHardFork`. This helps to initialize the
strucure `LastHardFork` from invoke context and sysvar cache.
Registering `SyscallLastHardFork` in the file `monorepo/programs/bpf_loader/src/syscalls/mod.rs` in method
Registering `SyscallLastHardFork` in the file
`monorepo/programs/bpf_loader/src/syscalls/mod.rs` in method
`create_loader` like other sysvars.
### Updating documentation
@ -93,9 +104,10 @@ We should add correct documentation for the new sysvar in `sysvar.md` file.
## Impact
Dapps will start using this new sysvar to correctly address the security concerns during network
restart. This will increase the reliability of solana cluster as whole and make dapps more confident
to handle edge cases during such extreme events.
Dapps will start using this new sysvar to correctly address the security
concerns during network restart. This will increase the reliability of solana
cluster as whole and make dapps more confident to handle edge cases during
such extreme events.
## Security Consideration
@ -103,5 +115,6 @@ None
## Backwards Compatibility
The dapps using the new sysvar could not be used on solana version which does not implement this feature.
Existing dapps which do not use this feature are not impacted at all.
The dapps using the new sysvar could not be used on solana version which does
not implement this feature. Existing dapps which do not use this feature are
not impacted at all.