The initial API only serves to demonstrate what the fields for projections should be, but the data structure itself is ridiculous. The code doesn't even compile right now, but I have little (read: no) incentive to fix it when I know this isn't what will be used.
type DotPoint: Vec<(BalanceOf, BlockNumber)>;
#[derive(Encode, Decode, Clone, Eq)]
#[cfg_attr(feature = "std", derive(Debug))]
pub struct Projection<DotPoints> {
// projections for total reward
total_reward: DotPoints,
// dilution to treasury on block author reward
treasury_dilute_on_block_author: DotPoints,
// block author reward
block_author_reward: DotPoints,
// dilution to treasury on relay chain validator reward
treasury_dilute_on_relay_reward: DotPoints,
// relay chain validator reward
validator_relay_reward: DotPoints,
// dilution to treasury on parachain rewards
treasury_dilute_on_parachain_reward: DotPoints,
// parachain rewards (eventually to be highest)
validator_parachain_rewards: DotPoints,
}
New Runtime Storage Approach: Projection as Trie
I'm increasingly fond of an architecture in which the projections are cheaply gossiped over some network and only some trie root is placed on chain with the projections as leaves that are kept off the chain...trie roots could be challenged by anyone such that responses from the member in question require a trie proof of projection with valid parameterizations in order to sufficiently defend against the challenge and seize the challenger's collateral. This means that challenges also have to be incentivized (and the chain requires high data availability).
It also relieves the runtime of performing all the constraint solving computation that would otherwise need to be done to verify that the projection subprojections don't outnumber the total minting projection for a Term. Verification would also be required to ensure that the TotalTerm constant corresponded to the length of every Projection variant's length.
The problem at hand is encoding the fields of Projection in a trie such that proving the adherence to the aforementioned variants is cheap and easy, but I don't know how to do this yet.
context is convoluted Projection struct
The initial API only serves to demonstrate what the fields for projections should be, but the data structure itself is ridiculous. The code doesn't even compile right now, but I have little (read: no) incentive to fix it when I know this isn't what will be used.
New Runtime Storage Approach: Projection as Trie
I'm increasingly fond of an architecture in which the projections are cheaply gossiped over some network and only some trie root is placed on chain with the projections as leaves that are kept off the chain...trie roots could be challenged by anyone such that responses from the member in question require a trie proof of projection with valid parameterizations in order to sufficiently defend against the challenge and seize the challenger's collateral. This means that challenges also have to be incentivized (and the chain requires high data availability).
It also relieves the runtime of performing all the constraint solving computation that would otherwise need to be done to verify that the projection subprojections don't outnumber the total minting projection for a
Term. Verification would also be required to ensure that theTotalTermconstant corresponded to the length of everyProjectionvariant's length.The problem at hand is encoding the fields of
Projectionin a trie such that proving the adherence to the aforementioned variants is cheap and easy, but I don't know how to do this yet.