-
Notifications
You must be signed in to change notification settings - Fork 10
FM-316: Top down mint increase circ supply #330
Changes from 3 commits
5294343
88db4e0
3af5b83
37cf468
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,6 +48,22 @@ pub struct FvmStateParams { | |
pub power_scale: PowerScale, | ||
} | ||
|
||
/// Parts of the state which can be updated by message execution, apart from the actor state. | ||
/// | ||
/// This is just a technical thing to help us not forget about saving something. | ||
/// | ||
/// TODO: `base_fee` should surely be here. | ||
#[derive(Debug)] | ||
pub struct FvmUpdatableParams { | ||
/// The circulating supply changes if IPC is elabled and | ||
aakoshh marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/// funds/releases are carried out with the parent. | ||
pub circ_supply: TokenAmount, | ||
/// Conversion between collateral and voting power. | ||
/// Doesn't change at the moment but in theory it could, | ||
/// and it doesn't have a place within the FVM. | ||
pub power_scale: PowerScale, | ||
} | ||
|
||
pub type MachineBlockstore<DB> = <DefaultMachine<DB, FendermintExterns> as Machine>::Blockstore; | ||
|
||
/// A state we create for the execution of all the messages in a block. | ||
|
@@ -64,8 +80,11 @@ where | |
/// execution interpreter without having to add yet another piece to track at the app level. | ||
block_hash: Option<BlockHash>, | ||
|
||
/// Conversion between collateral and voting power. | ||
power_scale: PowerScale, | ||
/// State of parameters that are outside the control of the FVM but can change and need to be persisted. | ||
params: FvmUpdatableParams, | ||
|
||
/// Indicate whether the parameters have been updated. | ||
params_dirty: bool, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just curious, I see this parameter updated but not read, is it used in other PRs? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are right, it's a bit obscure. The only reason I added it was to use it in genesis where the It's a bit convoluted, but I haven't found a nice way to do things. I tried with maintaining a copy of |
||
} | ||
|
||
impl<DB> FvmExecState<DB> | ||
|
@@ -90,7 +109,7 @@ where | |
// * base_fee; by default it's zero | ||
let mut mc = nc.for_epoch(block_height, params.timestamp.0, params.state_root); | ||
mc.set_base_fee(params.base_fee); | ||
mc.set_circulating_supply(params.circ_supply); | ||
mc.set_circulating_supply(params.circ_supply.clone()); | ||
|
||
// Creating a new machine every time is prohibitively slow. | ||
// let ec = EngineConfig::from(&nc); | ||
|
@@ -103,7 +122,11 @@ where | |
Ok(Self { | ||
executor, | ||
block_hash: None, | ||
power_scale: params.power_scale, | ||
params: FvmUpdatableParams { | ||
circ_supply: params.circ_supply, | ||
power_scale: params.power_scale, | ||
}, | ||
params_dirty: false, | ||
}) | ||
} | ||
|
||
|
@@ -142,8 +165,9 @@ where | |
/// semantics we can hope to provide if the middlewares call each other: did it go | ||
/// all the way down, or did it stop somewhere? Easier to have one commit of the state | ||
/// as a whole. | ||
pub fn commit(mut self) -> anyhow::Result<Cid> { | ||
self.executor.flush() | ||
pub fn commit(mut self) -> anyhow::Result<(Cid, FvmUpdatableParams, bool)> { | ||
let cid = self.executor.flush()?; | ||
Ok((cid, self.params, self.params_dirty)) | ||
} | ||
|
||
/// The height of the currently executing block. | ||
|
@@ -163,7 +187,7 @@ where | |
|
||
/// Conversion between collateral and voting power. | ||
pub fn power_scale(&self) -> PowerScale { | ||
self.power_scale | ||
self.params.power_scale | ||
} | ||
|
||
/// Get a mutable reference to the underlying [StateTree]. | ||
|
@@ -201,6 +225,23 @@ where | |
|
||
Ok(emitters) | ||
} | ||
|
||
/// Update the circulating supply, effective from the next block. | ||
pub fn update_circ_supply<F>(&mut self, f: F) | ||
where | ||
F: FnOnce(&mut TokenAmount), | ||
{ | ||
self.update_params(|p| f(&mut p.circ_supply)) | ||
} | ||
|
||
/// Update the parameters and mark them as dirty. | ||
fn update_params<F>(&mut self, f: F) | ||
where | ||
F: FnOnce(&mut FvmUpdatableParams), | ||
{ | ||
f(&mut self.params); | ||
self.params_dirty = true; | ||
} | ||
} | ||
|
||
impl<DB> HasChainID for FvmExecState<DB> | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,6 +6,7 @@ use crate::chain::TopDownFinalityProvider; | |
use crate::fvm::state::ipc::GatewayCaller; | ||
use crate::fvm::state::FvmExecState; | ||
use crate::fvm::FvmApplyRet; | ||
use anyhow::Context; | ||
use fendermint_vm_topdown::{BlockHeight, IPCParentFinality, ParentViewProvider}; | ||
use fvm_ipld_blockstore::Blockstore; | ||
use fvm_shared::econ::TokenAmount; | ||
|
@@ -28,14 +29,16 @@ where | |
} else { | ||
(provider.genesis_epoch()?, None) | ||
}; | ||
|
||
tracing::debug!( | ||
"commit finality parsed: prev_height {prev_height}, prev_finality: {prev_finality:?}" | ||
); | ||
|
||
Ok((prev_height, prev_finality)) | ||
} | ||
|
||
/// Execute the top down messages implicitly. Before the execution, mint to the gateway of the funds | ||
/// transferred in the messages. | ||
/// transferred in the messages, and increase the circulating supply with the incoming value. | ||
pub async fn execute_topdown_msgs<DB>( | ||
gateway_caller: &GatewayCaller<DB>, | ||
state: &mut FvmExecState<DB>, | ||
|
@@ -45,7 +48,14 @@ where | |
DB: Blockstore + Sync + Send + 'static, | ||
{ | ||
let total_value: TokenAmount = messages.iter().map(|a| a.msg.value.clone()).sum(); | ||
gateway_caller.mint_to_gateway(state, total_value)?; | ||
|
||
gateway_caller | ||
.mint_to_gateway(state, total_value.clone()) | ||
.context("failed to mint to gateway")?; | ||
|
||
state.update_circ_supply(|circ_supply| { | ||
*circ_supply += total_value; | ||
}); | ||
|
||
gateway_caller.apply_cross_messages(state, messages) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we already discussed this when we were reviewing top-down, and we said we would defer it to the future, but what is your take for when executing the message fails? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had to re-read my comments: To reiterate the main points:
|
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one, I like this approach! Yes, I was actually going to ask you why the
base_fee
wasn't included here.I would include it for now even if it doesn't currently change as we may want to expose a callback to update it for users in the future. But maybe you have a reason not to include it yet, so happy either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't include it purely because there is no user story for how to update it. I created an issue, but haven't checked what's happening in Lotus or Forest. Maybe it's based on the last N blocks or something? Or maybe it's based on some voting, I don't know. I'd rather have a TODO stating it's not done, then code which suggests it might be done, which sends people looking all over to code just to confirm that nothing is happening.
But the history of it is already maintained, so as soon as we add it here, the compiler will tell us to update the value in
app.rs
and all will be well.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep a static
base_fee
and not use what Lotus is doing, I would rather have a way for users to decide thebase_fee
function instead of giving them a really complicated one that they don't understand. So yes, let's leave it for the future. Thanks!