The GraphEntry type is the foundation for that and was developed from the native currency we had. So it allows the same native currency we had to exist in the data form.
I can try and help here where we we’re/are/going
Where we were - Old Native Currency
Used a thing like GraphEntry
GraphEntry has the value component that can be `spent in the outputs
we can check the outputs are non zero and sum to the value being spent.
So that’s all there now, however it also had
A genesis transaction that existed on the network (transaction 0)
This was then spent to various outputs and this is what became the currency, i.e. it spreads out.
The genesis tx was baked into the codebase and all nodes knew it
That currency spend forms a DAG and we had DAG does to follow and confirm the DAG and able to supply proof to users transactions were valid.
So all good, except the DAG and I did not like that as it was very heavy work and grew with time. However it proved it all worked and securely worked.
We had issues where a sybil attack could take over a transaction space, so we added a DISTANCE check to GET_CLOSE nodes and this meant any honest node in the DISTANCE is all we needed to keep it honest (this is a small trick but a very powerful anti sybil defence). Anyway that’s where we were .
Where we are
We still have the data types
They still perform as previously but no node checks at all, it’s all client side.
The client side checks is where I wanted to go anyway. So instead of nodes following a DAG and rebuilding all the way back to genesis the idea is
Have clients backtrack transactions based upon a complexity score.
The amount of transactions they go back will be randomised, but minimum values based on tx complexity (how many inputs and outputs etc.).
This gives us a mechanism that is stochastic and secured, but not guaranteed, however nothing is ever guaranteed. So this seems like a weak approach, but in fact may be extremely secure, it’s certainly very well decentralised and low on resource requirements.
Where are we going (technically, ignoring exchanges etc. which will make a difference)
However currently all GraphEntries are paid for, so there is a tx fee, although it is tiny. Anyway, that’s a question.
The actual algorithm needs a lot of research and security testing
It may still need DAG nodes (which would be bad IMO)
Bootstrapping it is simple, but distributing it may be more difficult
So that is a simple synopsis of Native currency, the aim is a completely decentralised stochastically secure lighweight massively concurrent (i.e. hundreds of billions of TPS) resource swapping mechanism (currency)
When we reach our final goal, would the ideal scenario be having zero transaction fees? Or would a small fee still be necessary due to the need for using GraphEntries?
It seems like the overall framework is now well-defined, and I look forward to the time when we can start implementing the detailed algorithms.
I did not fully understand the AT2 paper, but I believe that such research has laid the foundation for determining the overall direction. Because of this, I dream that we will eventually reach our goal.
I think we as a community should decide. I think it would be neat for a slight change to the data type to make it “different” from GraphEntry just by an identifier and that should be free. I would hope so anyway, but if not (which may be much simpler) then the fee should be very trivial and as this is all one token and native, it would be simple to use and people would barely notice the fee. That keeps it simpler for sure and the fee to be way way less than a penny or similar, so not spam protection type fee, but as other GraphEntry fee’s it’s almost negligible.
At least that’s my personal thought right now. So perhaps fees and keep it simple, but have the fees to be negligible.
Yes a lot of things over the last 5 years have really helped here. The DISTANCE measure for sybil avoidance coupled with nodes not being able to create data is a huge win and we have barely use that power yet, but we will.
I’m not sure if I fully understand, but it seems like the choice is between:
A more complex system with no fees, or
A simpler system with a very small fee.
(Of course, it would be great if there were a magical way to keep it simple while also having zero fees )
Understanding how a “complex system” would impact the network in the long run requires deep knowledge of the entire project code, so I don’t think I can contribute much to this decision.
I will choose to support the proposal made by the team with the deepest understanding of the system.
You have it. The complexity is not much at all, but sometimes it’s just good to have no complexity at all when we have the chance. So the balance is adding that complexity and having special handling of a data type in nodes, or just say the fees are so cheap as to be negligible and use the data types as they are. So a no change type currency, but one anybody can create and who knows, perhaps have many of them etc.
It’s not a huge issue though at all. The key thing, apart from that question, all the data types we need already exist
If the GraphEntry datatype is still subject to economic forces (node fullness) to increase its fees, I would rather see a copy/pasted data type be used that is free.
If you can peg it to, say, 0.00000000000000001 ANT, then sure, it’s essentially free. I just don’t want the situation to be where nodes get 95% full and suddenly it costs $3 to send $0.50 worth of ANT.
At those costs, the network would be dead I would think. The graph entry type is a tiny cost, it’s 1/20th of a chunk IIRC (need to check). So for that to cost even $0.0001 would be a massive surge in price.
But based on the white paper, the pricing growth curve is hyperbolic, so the price will approach infinity as nodes approach 100% full. I know the goal is that high prices will drive more people to start up nodes, but that’s not immediate, and it leads to a situation where, theoretically, a single transaction for even 1/20th a chunk cost would be very high.
That is true, however if the price went to near infinity then the network is close to dead. So there is a jump as the network get’s into trouble, but that jump means it’s gone really wrong if the price has jumped that much. At that time the networks in trouble, quite serious trouble.
So the other side of that arguments is, should we slow down work and storage (which is what the curve does too) so that the network gets a chance to slow and stabilise etc.
So it is a balance and there is 2 sides to nearly all of this. But the huge costs is really huge trouble and we should never get to that point all going well.
Why you choice Ethereum blockchain for ant why you dont made ant with own blockchain. On any domain. It will increase utility of etherum.. Ant will be behind Ethereum
We don’t want to create a blockchain developer team here. We are using this as a means to an end. It’s a mechanism to allow folk to provide resource and be paid and others to consume resource for payment. Blockchain can do that now to some degree, but can still suffer from speed basically. The other issue is fees, so we can get fast transactions but we also need the fee paid, which is slower and more expensive than we would want of data uploads. But it works for now.
A more native token with a significant throughput and no or minimal fees (i.e. almost invisible fees) with the same token would allow the network writes to speed up. Won’t affect downloads, but uploads (writes) are slower with the blockchain and will be faster without it.
If we get too fancy with blockchain or integrate, tweak and bend our network around it then we would be in trouble as it becomes a “lock in” technically and we want to avoid that at all costs.
Hi David, have you considered the lightening network? It surely is cheap and fast enough. Tether are about to launch USDT on it so tokens can now be created on it. It could be the best temporary solution for now. Exchanges are starting to intergrate lightening, so once USDT is on there and exchanges are using it, I can see it being the best option for cheap and fast payments.
Nostr has it intergated into it’s platform, so could be worth looking at how they do that.
And to add, other popular networks being able to easily intergrate into the Autonomi network might also have benefits for adoption. Just think of all those projects built on ethereum that are having to centralise all of their apps / websites. Uniswap seems like an obvious one that could benefit with Ethereum intergration.
Lightening network integration may bring Nostr devs over.
I like that appeal as well but I am afraid it would be wasted effort. Bitcoin maxi’s just bitcoin maxi mostly. If it veers too far away from solely bitcoin, they just don’t seem interested.
The bitcoin community is much more diverse than you think. I’m kind of a BTC maxi when it comes to money, but i’m obviously open to ideas for decentralization BTC can’t solve. Nostr isn’t built on btc because of course it never can be, so all the Bitcoiners there have to understand new tech that isn’t btc but uses btc.
The amazing thing about this project is that it mainly is trying to solve a big problem BTC isn’t trying to solve. Bitcoin is the base layer for sound money… Hopefully Autonomi is the layer for private, secure, anonymous data at least… anything else is a bonus.
The BTC community want true decentralization and sound money… knowing money is the biggest problem to solve. Sound data will be obvious to them. I do expect many of them to say why not have an Autonomi network that only takes BTC lightening, but maybe that model wouldn’t work with pay once store forever?
Anyway, at this point in time it seems the only viable solution for fast and cheap payments. The sooner we get that and easy ways to add data, apps, and websites to the network, the sooner we see the full potential of Autonomi.
)