You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 10, 2023. It is now read-only.
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.
typeDotPoint:Vec<(BalanceOf,BlockNumber)>;#[derive(Encode,Decode,Clone,Eq)]#[cfg_attr(feature = "std", derive(Debug))]pubstructProjection<DotPoints>{// projections for total reward total_reward:DotPoints,// dilution to treasury on block author rewardtreasury_dilute_on_block_author:DotPoints,// block author rewardblock_author_reward:DotPoints,// dilution to treasury on relay chain validator rewardtreasury_dilute_on_relay_reward:DotPoints,// relay chain validator rewardvalidator_relay_reward:DotPoints,// dilution to treasury on parachain rewardstreasury_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.
The text was updated successfully, but these errors were encountered:
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 theTotalTerm
constant corresponded to the length of everyProjection
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.The text was updated successfully, but these errors were encountered: