updating proposal to include some more information
This commit is contained in:
Godmode Galactus
parent
6aad723bbf
commit
349bad9b67
|
|
@ -0,0 +1,148 @@
|
|||
---
|
||||
simd: '0047'
|
||||
title: Syscall and Sysvar for last restart slot
|
||||
authors:
|
||||
- Godmode Galactus (Mango Markets)
|
||||
category: Standard
|
||||
type: Core
|
||||
status: Draft
|
||||
created: 2023-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Create a new syscall and sysvar that can be used to get the last restart slot.
|
||||
|
||||
A new Sysvar :
|
||||
`SysvarLastRestartS1ot1111111111111111111111`
|
||||
|
||||
Method signature for syscall:
|
||||
`fn sol_get_last_restart_slot() -> Slot`
|
||||
|
||||
## Motivation
|
||||
|
||||
In Solana, when the cluster cannot reach consensus, it is currently restarted
|
||||
using `ledger-tool` with a hard fork on a slot. All participating nodes need to
|
||||
restart their validator specifying the hard fork slot. Once all nodes
|
||||
participating in the restart effort 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.
|
||||
|
||||
Program developers may find it useful to know that a cluster restart 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 cluster restart has been done
|
||||
recently, programs can manage these cases more appropriately.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
We need to have the value of the last restart slot while executing the program.
|
||||
We cannot use 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 syscall and sysvar to get this information during the execution of a
|
||||
transaction, which will help us get the last restart slot. We prefer syscall
|
||||
over sysvar because the newly created sysvar has to be passed in the instruction
|
||||
this takes up transaction accounts space. In the long-term Solana evolution, we
|
||||
plan to get rid of syscalls and make everything a sysvar, so we have decided to
|
||||
implement both a syscall and a sysvar to address short and long-term evolution.
|
||||
|
||||
## New Terminology
|
||||
|
||||
None
|
||||
|
||||
## Detailed Design
|
||||
|
||||
The following criteria should be met to choose a restart slot.
|
||||
|
||||
* Should be of type unsigned int 64 bits.
|
||||
* Should be indicative of when the cluster was restarted
|
||||
* Should be monotonically increasing
|
||||
* Should be less than equal to the current slot
|
||||
* Should be synchronized in the whole cluster
|
||||
* Can also be indicative of a slow block
|
||||
* The first restart slot should be `0`
|
||||
|
||||
In Solana client `hard fork` variable satisfies nearly all the conditions except
|
||||
it is not indicative of slow block, it is a good candidate.
|
||||
|
||||
The syscall and sysvar will be available in architectures eBPF and SBF. Only the
|
||||
sysvar will be available from architectures SBFv2.
|
||||
|
||||
### Feature Gate
|
||||
|
||||
This feature should be protected by the feature gate this is because this
|
||||
feature can create differences in consensus. Solana core developers should
|
||||
create a new keypair and use it to enable this feature on the cluster.
|
||||
|
||||
Upon activation, the functionality described below immediately becomes
|
||||
available.
|
||||
|
||||
### Creation of a new sysvar
|
||||
|
||||
Similar to the clock or rent sysvar we can create a new sysvar for last restart
|
||||
slot. We have to implement a new class to store the required values, which then
|
||||
could be used by sysvar during execution.
|
||||
|
||||
Sysvar Id: `SysvarLastRestartS1ot1111111111111111111111`
|
||||
|
||||
### Creation of a new syscall
|
||||
|
||||
The implementation of this syscall is pretty straightforward. The syscall should
|
||||
have following signature:
|
||||
|
||||
`fn sol_get_last_restart_slot() -> u64`
|
||||
|
||||
Murmur3 hash is: `0xb532af38`
|
||||
|
||||
### Overview of changes for Solana client
|
||||
|
||||
In Solana Labs validator client all the cluster restart-related data is already
|
||||
stored in the bank structure. For other validator clients, we have to get the
|
||||
last restart slot information and make it accessible to the runtime of the
|
||||
program. We have to set this data in invoke context executing the program. Then
|
||||
the syscall and sysvar can use invoke context to return the data to the
|
||||
executing program.
|
||||
|
||||
### Compute budget for the syscall
|
||||
|
||||
As this feature involves moving a u64 from the bank to the invoke context and
|
||||
returning it when syscall or sysvar is called.
|
||||
|
||||
So considering :
|
||||
|
||||
```
|
||||
/// Cluster averaged compute unit to micro-sec conversion rate
|
||||
COMPUTE_UNIT_TO_US_RATIO = 30;
|
||||
```
|
||||
|
||||
We can set the maximum compute limit for the syscall to:
|
||||
|
||||
```
|
||||
COMPUTE_UNITS_LIMIT = 2 * COMPUTE_UNIT_TO_US_RATIO
|
||||
```
|
||||
|
||||
## Impact
|
||||
|
||||
Programs will start using this new syscall to correctly address the security
|
||||
concerns during network restart. This will increase the reliability of solana
|
||||
cluster as a whole and make program developers more confident to handle edge
|
||||
cases during such extreme events.
|
||||
|
||||
As the method is syscall the developers do not need to pass any new
|
||||
accounts or sysvars to the instruction to use this feature.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
None
|
||||
|
||||
## Backwards Compatibility
|
||||
|
||||
The programs using the new syscall could not be used on Solana version which
|
||||
does not implement this feature. Existing programs that do not use this feature
|
||||
are not impacted at all. Feature gate should be used to enable this feature when
|
||||
the majority of the cluster is using the required version.
|
||||
|
|
@ -1,113 +0,0 @@
|
|||
---
|
||||
simd: '0047'
|
||||
title: Syscall to get the last restart slot
|
||||
authors:
|
||||
- Godmode Galactus (Mango Markets)
|
||||
category: Standard
|
||||
type: Core
|
||||
status: Draft
|
||||
created: 2023-04-15
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Create a new syscall that can be used to get the last restart slot (currently
|
||||
the last time hard fork was done on the cluster).
|
||||
|
||||
`fn sol_get_last_restart_slot() -> Slot`
|
||||
|
||||
## Motivation
|
||||
|
||||
In Solana, when the cluster cannot reach consensus, it is currently restarted
|
||||
using `ledger-tool` with a hard fork on a slot. 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. Currently, we can consider the slot on
|
||||
which hard fork was done as a restart slot.
|
||||
|
||||
Program 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 cluster restart has been done recently, programs
|
||||
can manage these cases more appropriately.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
We need to have the value of the last restart slot while executing the program.
|
||||
We cannot use 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 syscall or sysvar to get this information during the execution of a
|
||||
transaction, which will help us get the last restart slot. We prefer syscall
|
||||
over sysvar because the newly created sysvar has to be passed in the instruction
|
||||
this takes up transaction accounts space. This will break existing program
|
||||
interfaces, and the transaction account space is limited which is already a pain
|
||||
point for many DeFi projects.
|
||||
|
||||
## New Terminology
|
||||
|
||||
None
|
||||
|
||||
## Detailed Design
|
||||
|
||||
Currently, in Solana Labs validator client `hard fork` slots are good indicators
|
||||
when the cluster was restarted. This may change in the future following criteria
|
||||
that should be met to choose a restart slot.
|
||||
|
||||
* Should be indicative of when the cluster was restarted
|
||||
* Should be monotonically increasing
|
||||
* Should be less than equal to the current slot
|
||||
|
||||
The next part will consider hard fork slot is equal to the restart slot.
|
||||
|
||||
### Creation of a new syscall
|
||||
|
||||
The implementation of this syscall is pretty straightforward. In Solana Labs
|
||||
validator client all the hard forks for a cluster are stored in the bank
|
||||
structure. The last hard fork slot can be retrieved and then stored in invoke
|
||||
context, so that the executing program can access it.
|
||||
|
||||
For other validator clients, we have to get the last hard fork slot information
|
||||
and make it accessible to the runtime of the program. If there is no hard fork
|
||||
done yet on the cluster we consider that the first hard fork is at Slot `0`.
|
||||
|
||||
### Overview of changes for solana client
|
||||
|
||||
The hardfork data is available in the `Bank`. 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 can register new syscall in the file
|
||||
`definitions.rs` where other syscalls are defined.
|
||||
|
||||
```rust
|
||||
define_syscall!(fn sol_get_last_restart_slot() -> Slot);
|
||||
```
|
||||
|
||||
We can then return the data of the last hard fork slot passed to the invoke
|
||||
context in this function's implementation.
|
||||
|
||||
## Impact
|
||||
|
||||
Programs will start using this new syscall to correctly address the security
|
||||
concerns during network restart. This will increase the reliability of solana
|
||||
cluster as a whole and make program developers more confident to handle edge
|
||||
cases during such extreme events.
|
||||
|
||||
As the method is syscall the developers do not need to pass any new
|
||||
accounts or sysvars to the instruction to use this feature.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
None
|
||||
|
||||
## Backwards Compatibility
|
||||
|
||||
The programs using the new syscall could not be used on solana version which
|
||||
does not implement this feature. Existing programs that do not use this feature
|
||||
are not impacted at all.
|
||||
Loading…
Reference in New Issue