The SugarFunge blockchain powers the SugarFunge Protocol. A protocol for creating privately-owned economies without the complexity of building and maintaining their own blockchain infrastructure. Empowering businesses with digital and physical assets with minting, crafting and trading mechanics.
Other
0
stars
1
forks
source link
Implementing a basic deeper proof that cannot be mutated by users #6
Victor Amaya
9 days ago
Note ** Issue here is because of Local IPFS - and developers having the access to Modify the code to assign a Files CID without actually storing the File itself.
We want to make sure that the Proof of Storage prevents developers to hack the Local Storage and Assign themselves a multiple amount of CIDs without actually storing the files.
15 replies
@Mauricio Morales
Can you please describe how the Proof Engine Verifies against this to happen currently?
Victor Amaya
9 days ago@rozgo
Does the Proof Engine currently prevent for this data to be modified on Local IPFS?
rozgo
9 days ago
This is mostly game theory. It’s in the node owners best interest to do the right thing. If he tampers or becomes a bad actor he will lose assets he has/staked on the chain.
rozgo
9 days ago
We do this with optimistic rollup and then anybody can challenge a node owner which will trigger validation checks and deeper proofs. If malicious activity is detected owner is quarantined and assets could be seized. Kind of like how bad validators may lose their stake if they don’t meet performance metrics. (edited)
:ok_hand:
1
ehsan shariati
9 days ago
Agree that we'l can be more going toward proof of stake where everyone needs to stake an amount. But what would be the deeper proof if someone challenges? I think right now we don't have any deeper proof?
ehsan shariati
9 days ago
Quarantining the storage provider is a good approach though
ehsan shariati
9 days ago
And verifying his stored data
ehsan shariati
9 days ago
Is it something we can have implemented?
I think there are 3 aspects to it:
1- staking requirement to be able to be a storage provider
2- an api that someone (file owner? Functionland?..) can trigger and request for a deep proof
3- the deep proof itself (edited)
ehsan shariati
9 days ago
For number 1, staking can come from the earned tokens. So we can let anyone become a storage provider, but with mandatory staking of all earned tokens until they meet a threshold and then we perform a deep check and from there on they can withdraw anything they earn om top of the staked tokens(the stakes ones still remain locked though) and still they can be challenged at any time
rozgo
9 days ago
The deeper proof can be a forensic script on the IPFS logs and other services. We can take inspiration from other projects.
ehsan shariati
9 days ago
I think we can combine. Quarantining the provider and asking him to provide some random bits,...
rozgo
9 days ago
The forensic code can be on-chain and do off-chain checks.
ehsan shariati
9 days ago
Can you assist Carlos team on implementation? We have limited proof knowledge in the inhouse team to help here.
rozgo
9 days ago
Yes. I’ll get a core implementation going and the team can take over.
Victor Amaya 9 days ago Note ** Issue here is because of Local IPFS - and developers having the access to Modify the code to assign a Files CID without actually storing the File itself. We want to make sure that the Proof of Storage prevents developers to hack the Local Storage and Assign themselves a multiple amount of CIDs without actually storing the files. 15 replies
Victor Amaya 9 days ago @Carlos Lopez
@Mauricio Morales Can you please describe how the Proof Engine Verifies against this to happen currently?
Victor Amaya 9 days ago @rozgo Does the Proof Engine currently prevent for this data to be modified on Local IPFS?
rozgo 9 days ago This is mostly game theory. It’s in the node owners best interest to do the right thing. If he tampers or becomes a bad actor he will lose assets he has/staked on the chain.
rozgo 9 days ago We do this with optimistic rollup and then anybody can challenge a node owner which will trigger validation checks and deeper proofs. If malicious activity is detected owner is quarantined and assets could be seized. Kind of like how bad validators may lose their stake if they don’t meet performance metrics. (edited) :ok_hand: 1
ehsan shariati 9 days ago Agree that we'l can be more going toward proof of stake where everyone needs to stake an amount. But what would be the deeper proof if someone challenges? I think right now we don't have any deeper proof?
ehsan shariati 9 days ago Quarantining the storage provider is a good approach though
ehsan shariati 9 days ago And verifying his stored data
ehsan shariati 9 days ago Is it something we can have implemented? I think there are 3 aspects to it: 1- staking requirement to be able to be a storage provider 2- an api that someone (file owner? Functionland?..) can trigger and request for a deep proof 3- the deep proof itself (edited)
rozgo 9 days ago Yes
ehsan shariati 9 days ago For number 1, staking can come from the earned tokens. So we can let anyone become a storage provider, but with mandatory staking of all earned tokens until they meet a threshold and then we perform a deep check and from there on they can withdraw anything they earn om top of the staked tokens(the stakes ones still remain locked though) and still they can be challenged at any time
rozgo 9 days ago The deeper proof can be a forensic script on the IPFS logs and other services. We can take inspiration from other projects.
ehsan shariati 9 days ago I think we can combine. Quarantining the provider and asking him to provide some random bits,...
rozgo 9 days ago The forensic code can be on-chain and do off-chain checks.
ehsan shariati 9 days ago Can you assist Carlos team on implementation? We have limited proof knowledge in the inhouse team to help here.
rozgo 9 days ago Yes. I’ll get a core implementation going and the team can take over.