No it doesn’t - it just decouples address owner from content owner
Right now nodes check both the content being valid and the location being correct against the signature of the same owner key (the pointer address). The proposal is to use 2 different secret keys for 2 different things (address validation/derivation and content validation)
No more as they can with pointers, graphEntries and Scratchpads already
In our proposal
The user is free to choose the private key leading to the address (it’s basically a shared private key with everyone who should be able to retrieve the data)
for creating the owned pointer the user then needs 1. The (address) private key leading to the data address
for modifying the content he then needs 2. The (owner) private key to validly sign the new content for changing it
Ps:
You could even enforce the data being signed by both keys to make sure nodes can validate the Adress not being ‘made up’ and the data wasn’t introduced by bad nodes if that’s the fear here
Thanks for getting back on this @chriso - it’s much appreciated for community engagement and helps us to support the project.
I’ll respond with my thoughts to each point above. I’ve also created a draft PR, as it may make more sense to move the conversation to code specifics:
This is important feedback, as it was suspected the key-addressing and content-addressing were for fundamental reasons. If this feature is to be added, we need to be certain it is safe.
Currently, a mutable address is defined using a public key, derived from a private key. Separating the address from owner doesn’t fundamentally change this - a public key is still used to derive the address. However, the public key for the address is provided directly (see point 5 for more): Separate owner address mutables by traktion · Pull Request #3073 · maidsafe/autonomi · GitHub
This is a concern, but it is also true for all mutable types (same key => collision). You can still use the owner key (as a derived public key) as an address key and the previous behaviour is unchanged. Using a known public ‘private’ key as an owner key would be ill advised (at best!), so the chance of collisions should be removed (see point 5 for more).
However… this does assume that the public key is derived from a private key, rather than a spurious process. If an adversary wanted to target a specific address, as long as it was a ‘valid’ public key, it could be done with the implementation in the PR. Regardless, they couldn’t change the data at an existing location (as they don’t own it - see 3).
If address targeting is a concern for different reasons (to apply load to a known group, etc), the client could require a signature for the address as well, to provide authentication that it was generated from a valid private key. To target a specific address would then be just as difficult as regular key-addressing on owner keys (i.e. near impossible).
@Anselme thanks for looking into this - it’s really appreciated. If you’d like to direct any specific comments to the draft PR code, please do so too. It’s warts and all, with no consideration for unit tests, etc. It isn’t intended to be merged (at least not in this state! ha!), but more to encourage conversation around this.
Just to come back on this initially, we discussed it on our call, and there are more than just technical considerations around this subject. We are going to be discussing it with David and some other people who have been involved in the finance side, and will have a response. It might just take a little time, but we will absolutely get back to you about it.
Thank you very much - it doesn’t immediately be connected to finance - transferable ownership would be pretty powerful by itself as a concept in the network, transferable Tickets, transferable names,…
Maybe it is best to separate changing owners/addresses and building out native currency too?
There are many benefits from being able to change the ownership of types, mostly unrelated to tokens or finance. It’s more about easy address resolution and write permissions in many/most cases.
Ofc, finance use could build on top of these, but surely it would be a stretch to prevent the above, just because of this?
I look forward to hearing more either way. Thanks again!
Yeah, I will emphasize this and we can discuss that as a separate thing.
For now, we will put a DoNotMerge label on this PR. Please don’t be alarmed by that or take it the wrong way. It doesn’t mean it ultimately won’t be merged, we just need to make sure it doesn’t accidentally come in too soon.
And yes it’s clear that in theory it can be done by creating chains of graphEntries that point to data chunks that can be traversed and validated etc… But that means creating a DAG and needing to validate and secure it, resolving invalid branches, depending on the application thousands or even insanely more calls and complex logics to resolve all possible error cases … Where just querying one data point and validating the owner field would be enough if we had ownership as a concept…
It could take a lot of complexity off developers hands for applications where the history of ownership is irrelevant.
I read the sn_dbc docs and it left me wondering how you transfer the DBC. It seems to me that we still need a way to change ownership of mutables, even with DBCs.
With the current version of autonomi, ant nodes can only choose to persist a proposed change or deny it. They can’t mutate the data again, as they don’t have the private key to sign the changes, so clients would reject it.
So, how are a DBC ‘spent’ if ownership cannot be transferred?
If DBCs add additional privacy, that’s great, but surely they need to based on a mutable type that can be transferred though?
What if there is no minting of new tokens beyond what people convert from ANT to spend?
Supply is then regulated by what folks are willing to convert and spend on data.
Demand would still be driven by node runners, bit they could just receive what folks spend.
No need to worry about how to create new tokens, other than a smart contract to convert blockchain ANT to native.
The remaining challenge would then be how to direct spends to node runners. Maybe that could be a client library thing, where a node is picked at random for a reward? Keeping it simple that way.
I’m not 100% sure, but I remember speed issues were with tracking DAG for rewards purpose. Validation would be needed just for one step back, if it’s done by nodes as part of validating PUT operation.
Isn’t the fact, that the uploader has to pay each node separately for each chunk the main bottleneck? The global rewards, distributed from central pool are and likely will be the main source of rewards. Since this redistribution mechanism has to stay, why not simply let everyone pay to that central pool, and not only for 1 chunk, but 1000 or even more prepaid chunks at once?
I know, there is the mechanism, where nodes say different price per uploaded chunk. But they churn data anyway, so in fact it does not matter who was paid, in the end someone else will be holding that data. So it should average out. Why not have more general consensus on what is current expected cost for upload to network and let the uploader pay that price to the central pool?
As a result, we could have prepaid credit, that can be only burned(decrease counter of available chunks for upload in consensus). No transfer of ownership, just proof of burn when he uploads. Which means no legal risks, since such credit by definition is not crypto. Node would have to accept proof of burn an let uploader store the chunk. But we would gain massive speed in uploads and remove all the crypto related nightmare on each chunk upload. only buying credit would be crypto transaction. Nodes would still earn erc20 ANT, but only from that central pool, which would reward same number of transactions, but increased value, since it would also redistribute last day payments form uploaders.
I know I am repeating myself, but based on what I see it looks to me a reasonable compromise solution, where we keep erc20 and still can have fast network and earning from home.
Optionaly: Earning nodes could be paid simply in upload credit, if they wish, but upload credit would not be transferable in any way.
It’s an interesting challenge for sure. I think this underlines that there is a substantial body of work to do to make it happen.
When changing ownership, the new owner can be a burn address, so there is a mechansim to do that. However, then we need to track which burned tokens have been consumed for storage, which would seem to put us back to the start.
If a direct transfer of token from user to node can be accomplished, it feels very much like a regular trade - storage for token. However, the node storing the chunk would know the address of the previous owner and what chunk was persisted.
Have to be brief now and I definitely don’t have all the answers, so just sharing thoughts.
That part is easy. it is just a client signed message, where he signs what chunk hash to which client id is he purchasing with his credit.
Lets reuse current technology. Right now we have scratchpad data. Imagine, that instead of rewrite it would be append only. This means, I have 1 single hash representing that chunk and I can append to it all my spending of credit. So this means, I can do erc20 transaction, using smart contract, where I simply pay to the main pool, but I also provide to that function an ID of that appendable chunk and a hash of initial content of that data. That initial data can be something like "{ chunksCount: 1000}". Now the contract verifies that the hash matches the amount and stores it on blockchain. Ethereum contract can store such hashes. This way, any node in Autonomi network can check, that the initial first data in that chunk was paid correctly with ANT. They just need to call transaction id. Now, the client has proof he paid for that count of chunks and he can proof that the payment was valid and initial amount is correct. So this is basically a bridge from ANT to credit. From now, there comes spending part. Client will simply append to that schrachpad transaction of spending.
Like "{ purchase: [ {nodeid: XXXX, chunkUploadId: YYYY,...}]}".
Than it publishes this to the group responsible for that YYYY chunk upload. From now, all nodes act like before, just store information, that node XXXX has to store chunk YYYY,
So his proof of spending is just ID of that scratchpad + Id of original transaction on Arbitrum. From that every node can verify that he paid for that credit and that he validly purchased that chunk. We are not limited by 4MB of scratchpad , because when it is about to fill, simply append there address of next scratchpad data block(this one has to be purchased form that credit).. So we can have single erc20 transaction purchasing credit, and minichain of spending of that credit stored in appendable data in scratchpads . We only need to introduce append only scratchpad data type.
Edit: It is blockchain like spending, but if anyone wonders whether this will make uploaded hashes public, there is simple trick, instead of spending with ID of chunk, we can store there HASH(Id), and tell real Id only when broadcasting chunk purchase to the closed group. This way privacy is 100% preserved and impossible to track which chunks were purchased.
This requires a bank sort of mechanism. Something to hold funds to distribute and also has to be auditable if done by the foundation like emissions are. Remember whatever is done under the foundation’s name/action has to be auditable and records kept and be able to be audited by the Swiss regulators and/or tax system.
Basically it would not be sensible to have this mechanism as part of emissions since that is random. Cannot just dole out a %age to every single node since there is no way to know what nodes there are. There is no registry of nodes to receive the %age.
The issues comes down to the mechanism, and how would one implement it. The network is supposed to be paying those chosen by the client app to have teh chunk written to. The churn is a requirement to be part of the network, not a right to be paid.
Although what you say at the end has some ideas that could make it workable
Maybe the credit note (limited in scope and quantity) could help here in that there is a smart contract that can receive a payment and issue this “credit note” to the client. Then the client pays the nodes with this split up credit note. The nodes can then redeem the credit notes received for ANT (via smart contract) when they have over a certain amount. The credit note can probably have a (random) ID issued by each node to be paid so that when the credit note is split up into individual IDs (w/amount) the client cannot cheat
This is only useful in the short term until native token kicks in. And since the payment amounts are so small then the amounts in any credit note is tiny and not useful for a general payment system
Security would be an issue still, even with tiny amounts involved. The “bank” account should not be a “honey pot” since it will only ever be holding small amounts, maybe up to 100 or 1000 ANT at any one time if a lot of uploads are happening.
BUT all this requires valuable dev time taken away from getting the network ready to proceed with native token development
I like the idea of reembracing something like the original concept.
In the case that individual native coins are stored on the network as an appendable list of ownership, with other items like parent coin addresses, and child split addresses to manage divisibility…
Would this become a set of 1.2B block chains where there is one block chain for every whole ANT coin?
Nope, we already have this redistribution. My proposal is simply to pay to the emission pool. This pool is used daily for emissions. So instead of paying currently 2 million of ANT per month, it would pay original 2 million + all what was collected into that during that time period. The count of transactions will stay the same, just the amount paid per transaction would increase based on what was paid. Nothing need to be changed. There can be separate address for collecting payments and once per 24 hours send full amount to he daily emission pool.
Direct payments are also random, we are paying a node for holding the data, he gets paid, than goes offline and someone else has to hold that chunk. There is literary zero sense in paying the node directly. Total random reward. It all averages out over time and acts like random reward.
This “network si supposed” is total nonsense. It was likely some original design idea 20 years ago. It evolved. We have emissions, which are also centralized but in reality of erc20 token emission payments are the only working reward mechanism. Direct payments over erc20 per chunk are expensive and the main bottleneck of whole design. This has to go. There is not “networks is supposed” to pay per chunk foundation in erc20 token implementation.
We don’t need any smart contract. The simple fact that ethereum/arbitrum transaction allows to include some extra data means we can store hash of any text there. Basically I as a buyer of credit can create any document, hash it and store the hash of that document in that ethereum transaction purchasing that credit. From that moment I can forever proof, that I did a purchase, and the purchase was for that hash.
So I as a uploading client don’t need to publish anything. But at the moment when I want to use my credit, I can simply send my unhashed text and id of that purchase transaction I made in the past on Arbitrum to the group where I want to store my chunk. That open text would be simple json =“{Prepaid_ANT= 100ANT, autonomiChunkId = XXXXXX}”.
They can instantly check on arbitrum network that the amounts ANT paid in erc20 matches the text in JSON, and they can calculate hash of that JSON and verify that it is exactly same in the ehtereum transaction. From that moment, I have ant token receipt on Autonomi. I basically created own proof of creation and in that proof is written that all transactions will be appended into autonomiChunkId = XXXXXX(This is Id of public appendable schrachpad, where I will store my transactions for each chunk upload).
When I want to upload, I will just ask nodes for quotes, same way as is done now. They will quote me. I will pick the quote I like, and append into appendablepublicSchrachpad XXXXXX the purchase transaction { hash(purchaseChunkId) = “ZZZZ”, costANT = “ddd”}.
And I broadcast my upload request with that transaction appended in that public appendable schratchpad. This is proof that I paid for that. Since it is appendable only, it acts like mini blockchain. Anyone can verify it. But I am not storing id of chunk, but hash of chunkID, so it is public but nobody knows which chunks I uploaded, until I tell them chunkID. (For improved anonymity hash(chunkId) can be replaced by private key encryption, we need public transactions count and transactions spendAmounts, but actual chunkId can be encrypted and revealed only to nodes during upload)
Each transaction decreases credit for the costANT = “ddd”. Close group can loop over whole history of those speeding very fast that I did not spend all the credit in previous transactions and my request is valid. Since they know the id of chunk, they calculate hash of it and compare whether it is in that transaction history. Bang, and from that moment everything continues. I just proofed I paid for the chunk, transaction is appended, so everyone knows the credit was spent.
This mechanism can even work in parallel with current direct payments. Node send quotes and he will not know in front , whether he will be paid in direct erc20, or whether it will be prepaid credit which was paid into central emission pool. Prepaid credit is not transferable, it is just spending of the credit for chunks… Absolutely easy to implement in current environment, no need for special consensus or anything extra… We just need public appendable chunk. Which can be appended up to 4MB. This appendable structure prevents double spending and allows verification of available credit by anyone.
When you realize that network will keep all the current code and just need to add another simple checking of simple JSON it is mind blowing.
→ It keeps quoting mechanism
→ It does not change direct payments nor number of emission transactions
→ the client software does the work, and nodes just check new payment alternative
→ It requires public append only chunk data structure
