$0.013 is 30% more than $0.01 whatever you paid for your tokens… but if you bought at 10% of current price, you’re doing far better than if you had to buy those tokens today.
Irrespective, it’ll be better with native ASAP.
5 Likes
Cannot agree more. It will make it 10000% easier to use the network when uplaoding
12 Likes
now that looks suspiciously like the ability to set one private key / recipient address for a number of nodes (to not needing to collect singled nanos from many different places) 
looks like collecting earnings will get a lot easier =)
…my deployment scripts will need a rework I guess …
8 Likes
Running the Node
To run a node and receive rewards, you need to specify your Ethereum address as a parameter. Rewards are paid to the specified address.
cargo run --release --bin safenode --features=network-contacts -- --rewards-address <YOUR_ETHEREUM_ADDRESS_TO_RECEIVE_REWARDS>
More options about EVM Network below.
5 Likes
and the safenode-manager has a new argument:
6 Likes
I realised I messed this analysis up by getting the current chunk size wrong; in current tests I think it’s 4mb max per chunk, not 32mb.
If this is the case, then with the other assumptions the same, the fee would cost not 30% of the total cost of storing data, but 76%. ($0.003986/($0.003986 + 0.00125)).
(0.00125 is the previously assumed ~6x SSD cost per mb, but as it’s 4mb vs 32mb, it’s $0.00125 rather than $0.01 per chunk.)
This means the fee would be costing over 3x what the nodes are getting paid, or the total cost to store a 4mb chunk would be about 4x what it’d be with the Native token.
If we needed to go to 2mb chunks for stability purposes, and each chunk required the same fee, which I’m assuming to be around:
… then the situation would be way worse, with storing data on Autonomi with ERC20 costing around 7x what native should cost.
Is this thinking correct?
Even with a 4mb chunk size, if the Arbitrum fee is going to be around 3x what we could reasonably expect to be the market rate for storage on Autonomi, then it’s a big reason to ensure the Native token is ready ASAP, as operating with ERC20 only will be a massive cost disadvantage for Autonomi & will not indicate the true potential of the network to the market.
Hope I’m missing something, but I fear I’m not… I’d like to see others make some estimates of reasonable pricing estimates for nodes to store data + the expected fee cost to see how big the fee is with other people’s assumptions in play.
I’d definitely like to hear the view of this team member:
… on their expectation of fee size as a proportion of total storage cost with ERC20 only payments.
3 Likes
Does the contract thingo change this analysis. Large files upload results in payments for every 256 chunks which each contract execution breaks up into 256 nodes being paid.
1 Like
I expect that would significantly improve the outlook for larger files, assuming the fee for executing that contract is a fraction of 256 * the fee cost for storing a single chunk.
If it effectively divides the $0.003986 fee by 256 then the ERC20 fee would become close to irrelevant where that method can be used.
I hope that is the case
It’d be nice if the team could share some of thier numbers on this… though I know they have so much going on.
5 Likes
It is beginning to be fairly obvious that the push to make 4MB chunk size work is the fee issue. Bigger max chunk size reduces the fee costs a lot more. But at what expense, we all run data centre nodes in DO data centres to get that sweet optimised networking between nodes? Are we swapping fee costs for renting dedicated VPS machines?
7 Likes
If the maximum size of a chunk is 4MB, a transaction allows up to 256 chunks, and the fees are, for example, $0.75, this means that storing 1TB of information, under optimal conditions, would cost about $750.
A transaction with fewer chunks will be cheaper but the cost per byte stored will be always higher than the optimal conditions mentioned earlier.
Since the transaction cost depends on the number of chunks, regardless of their size, the cost per byte stored, of files smaller than 12MB, increases significantly, with the price skyrocketing in the case of small-sized files. This makes the network, in practice, unviable for storing most standard daily information, which consists of small files.
Under these conditions, and with these prices, I find it very difficult for the network to be more than just a simple showcase. This reinforces the absolute necessity of having a native token to avoid these enormous costs.
7 Likes
So that would mean my MAID which cost me 2 cents to buy back in the day and seems will be able to do like 100K transactions of chunk uploads (random distribution of file sizes - say holiday photos) would end up costing 100 times that $0.75. 2 cents to upload from 100K chunks to 256K chunks and cost me $75.00 to use that 2 cents.
Surely this cannot be the case. Please tell me that is not right
1 Like
I’m not spending time digging into detail much now so can’t answer.
The are though going to be many consequences from these changes, some apparent others not.
By all are moves away from the native token that we understand, and also from the goals? that we want to achieve.
2 Likes
I have only calculated using the variables and data that we know. If anyone sees any errors, please point them out.
For example this transaction:
I believe it’s three chunks and the payment to the foundation so the fees of each chunk costs $0.001328666666667 or about $133 per 100.000 chunks.
Looking at the blockchain, large transaction show similar fees per chunk ($0,00133 to $0,00146). It seems they want to increase the number of chunks in a single transaction to 512 but this does not save on the fees per chunk, which are quite stable.
The fees per byte will obviously depend on whether we take advantage of the maximum size allowed for each chunk. In a ridiculous calculation, of course, if we store files of 3 bytes, the fees per TB would exceed one and a half million dollars.
The fees are what they are, and in my opinion, they make the network, in most cases, economically unusable.
5 Likes
This is possibly incorrect. If the current rules are followed, every chunk will require two payments, one to the node and another to the foundation, so in the end, the fees for storing a chunk would be double (about $0,0026 to $0,0029).
Similarly, the transactions that can be seen on the blockchain with 512 payments would actually correspond to the storage of 256 chunks.
This would confirm the initial calculations of fees around $700 per TB, as long as the maximum chunk size (4MB) is optimally utilized.
1 Like
Foundation payments are history now, no?
1 Like
oooooh - right - foundation payments would be an additional output xD … guess we’re not changing a singled thing because we’re adopting a blockchain now 
2 Likes
Did they not say that there will now be a genesis allocation to the foundation instead of royalty payments?
I don’t know - nothing
1 Like
Pretty sure unless I am dreaming. And this here is one good reason.
Royalties were a bit contentious anyway.
3 Likes
well … I see uneven numbers of TXs in the blockchain … and from previous estimations here it would double fees (that are pretty annoying anyway) if payments would include a royalty payment too … so you’re probably right … there are good arguments against it … in blockchain world …
2 Likes