updating proposal to include some more information
This commit is contained in:
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