Native currency

Development
62

There would be no guarantee that any community effort on this would be used by the team for the official Native ANT implementation, but hopefully it would at least push forward thinking in a way that helps the team.

Would this concept potentially be 2-way, i.e. ERC20 locked & wrapped to a Native Autonomi format, then burn Native format to unlock ERC20? If so it could be a great basis for getting assets onto Autonomi to form a dex (one way would be useless for this purpose, because if someone bought wrapped ETH on an Autonomi based DEX, it won’t have value if it can’t be used to unlock the corresponding ETH).

I think it would make a lot of sense that any community effort on this has purpose beyond being adopted as the official Native ANT, e.g. forming the basis of a DEX / being able to wrap ERC20 or other standard tokens to become Native to Autonomi. That way, it’s not wasted effort if it’s not useful to the team.

4 Likes
63

Thank you very much - I am sure there’s other/more elegant/better solutions too but I am confident it’s one that would work and therefore think it’s clear that the possibility for an exchange to Native is out of question (and that you have another solution too already this short after TGE shows that this can be spec’d out when the time is right and there is no need to pressure the team now…)

As I said I think other things should now be the priority… Without the basics working there’s no point in a native currency… Just think about the situation of the last couple of weeks with no uploads succeeding in native… TXs would have been brittle too, download of the dag info unreliable… Even if an exchange would have had listed us it’d be super pissed now with txs not working properly …

… And that situation still isn’t resolved fully
In this second the erc20 is making the network more reliable and helping us…

3 Likes
64

Other things are the priority for the team at the moment, and rightly so. As you say, what’s the point in Native if the network doesn’t function.

But, I do see a point to Native ANT as soon as the the basics are working reliably, because it massively reduces the cost of uploading. That seems like a big benefit to me. It seems the latest update was a significant step in getting the basics to work fairly reliably, so perhaps it won’t be that long before it’s justified for the team to start diverting a small portion of focus towards native token development (we’ll see in future updates when this happens).

Beyond Native ANT though, Autonomi Native Token standards development by the community could also lead to proof-of-concept DEXs etc, which I also don’t see as a pointless exercise.

To me, the sooner Native ANT happens the better. If community work can possibly help make this happen sooner, at the same time as laying groundwork for Autonomi based DEXs and Defi, then great… but being a non-dev with little time available, I can only cheerlead for anyone who wants to work on it, or help fund them, which I’d be willing to do along with others if any devs have a clear proposal.

9 Likes
65

Sure - but so far I think the only one who worked with registers (and therefore graphEntry under the hood) was happybeing - graphEntry would most certainly be the foundation of a token.

Scratchpad and pointer are not working afaik, nobody ever tried what happened on collisions for graphEntry (especially in such a large network).

Before we started beta everything was ready too (except for api) we even had a native currency that worked well from the community networks and maidsafes internal tests. :wink:

Not saying you’re wrong - all good and all correct - my very personal opinion is that we first need apis and devs testing and hammering the network for at least 1 or 2 years after the basic data types are implemented in a fully functioning way and available to test for everyone before we should think about going native… The first sign of anything working doesn’t mean we’re there tomorrow…

Edit/Ps: and if really interacting with the live network out there you will have recognised that operations (especially write and anything Scratchpad related takes easily in the area of minutes… Up to two digits of minutes on a vps - I suspect because of the limited possibility to cache the status of mutable data) so chunks can be fast atm because they’re stored more like Blockchain style highly redundant in the currently empty network - as soon as we’d switch to a native currency and because of the insanely low prices the network would fill and we wouldn’t have such a highly redundant storage capacity anymore +all data would need to be read from their immediate close nodes => performance on all data types would be in the area of current Scratchpad performance… So 3-10+ minutes per read/write operation from vps
… The network is by far not ready for native token atm… Imho…

7 Likes
66

Yes and no. It is evident that ensuring both uploads and downloads function correctly is critical and a priority above all else. But it is also true that the network will hardly be able to grow while it remains enslaved by fees that eat the profit that should go to the nodes.

I’ve also been thinking for several months about how a native token could work in the current situation, and I had reached conclusions similar to yours and @loziniak: leveraging the existence of a TX ID on the Arbitrum network, corresponding to the freezing of a certain amount of ANT, which would serve as proof for the creation of the same amount of native token on the Autonomi network.
By writing in the same XOR position as the TX ID, it could be easily verified that the tokens frozen on one network and created on the other correspond, ensuring the Bridge is correct.

The verification, in each DAG, for a payment or transfer will be not only be based on the Autonomi network but would always be initiated by the existence of a freeze on the Arbitrum network, significantly increasing the security of these transfers.

Obviously, this modifies one of the fundamentals that had always been discussed, which is the existence of a single genesis. In this design, there would be millions, or billions, of genesis events, which may or may not be desirable, but I see no impediment to being able to verify that the number of Native Token, existing at a given moment on the Autonomi network, correspond to the same number of ANT frozen on the Arbitrum network.

The reverse process (native token → ANT) could be carried out through a burning process on the Autonomi network and an Oracle on the Arbitrum network.

These basic ideas are just an outline that raise many questions, but they could be a path worth exploring since their potential benefits are immense. Personally, I’ve always been very critical of using a blockchain in Autonomi, but perhaps there’s a chance to enjoy the best of both worlds: economics access, with a security base, on the Arbitrum network, while payments for data storage and transfers remain free from the fees that are suffocating us.

6 Likes
67

I’m not sure the discussion went in the right direction, @loziniak proposed to take advantage of the fact that the alpha/IF/devnet is to become a separate network where applications can be tested, and this would also allow work on the native token to begin.

1 Like
68

Which is a smart point - but then again I think it does make sense to have a dev network das works precisely like main net and just is connected to a testing Blockchain… That’s the point of a dev network… To have something that is the same just doesn’t cost a lot…

Medium to long term an additional ‘test network’ might be added that does test the native currency…(or the dev network might get the native currency as optional parallel currency)

That’s ofc just my view on this matter…

7 Likes
69

I think this would make more sense.
By all means lets get the planning and some code ready for testing on a dev network that we will have already proven to a greater or lesser extent.

8 Likes
70

The proposal to create a test network that would be a technology sandbox was not intended to do anything other than support the team’s work in developing the network. It was obvious to me personally that a technology as advanced as Autonomi would face many unforeseen problems, and the launch of TGE would serve to test mainly for scalability, resilience and performance, so the proposal to launch a second, parallel network that would not be a fork but a fully team-controlled test network seems to me a natural step and now we have the opportunity to do so. While it may not be considered the best solution, being able to test ideas, applications but also work on the native token without any consequences for the development of the main network may bring more benefits than complications.

Would the community be prepared to support the sandbox with its resources, to start work, test and share feedback in order to relieve the burden on MaidSafe and speed up the amount of work that needs to be done?

4 Likes
71

This is a good point. Also, perhaps it’s too much work to prepare NT before DevNet launch by the team. But @Southside also has a good point, non-exclusive, that the work could begin now. Everybody can test Native Token on their local testnet, and when time comes, we could even try a comnet.

What do you think such proposal should include?

I wonder how that could look like? Perhaps each dev wanting to work on that could just publish an Arbitrum address with a rate per hour, and just work as much hours, as the incoming transfers on that address, then publish a report every week (day?)

Add me to this list :slight_smile: I’ve developed a high-level Register-like structure based on Scratchpad, GraphEntry and Data for Jams, even before the official Register based on new types.

Could perhaps timing problems be influenced by reliance on blockchain? Maybe it could be faster with Native? I think at the moment fast transactions are not that important, while we are testing. If we were waiting for uploads, why don’t wait for native transactions!

I’ve just tried to run full test routine of the Register type I mentioned, it took 28 minutes, you can check on the blockchain. It’s not fast. But it’s working! :slight_smile:

reg_test_mainnet.log.zip (868 Bytes)

A safenet-community Github organization could perhaps be a good place to set-up a project to coordinate the work and leave it out of this forum? Or should we at least wait on MaidSafe’s say on this initiative?

We are the community :slight_smile: Some will support this, and some will not, and that’s fine I think. At least we won’t be able to say we didn’t try. Everyone’s invited!

7 Likes
72

Scratchpad updates and reads don’t involve a payment - I was just referring to the real network delay for Scratchpad interaction I saw so far (not local devnet which I know is super fast… But doesn’t have anything to do with real world experience for all I know)

2 Likes
73

If you are developing for the current network then you must have the same setup as the current network.

74

Here we are, DM me or @aatonnomicc for access

4 Likes
75

Good question.

I guess it’d look different based on what any dev wants to work on, but to me the key things needed at a very high level are:

  1. Proof-of-concept Graph Entry based token creation & transaction implementation with basic wallet

  2. Proof-of-concept Graph Entry Token issuance based on ERC20 lock proof

  3. Proof-of-concept ERC20 unlock based on Graph Entry Token burn

But in terms of a specific proposal, for people to decide whether they want to chip in to support the dev work, I expect people would like to know;

  • what work the dev wants to achieve
  • how they plan to do it
  • how long they expect it to take
  • and how much they need to be paid to enable them to do it

I like that concept… dead simple, and kind of pay-as-you-go based on demand and results.

If a few devs are interested, it may be worth throwing ideas around between them so they can collaborate & specialise to achieve more together vs getting 2 or 3 totally different implications, though of course that would depend on devs having a shared idea of how to do it & being able to work together.

Sadly with markets the way they are perhaps everyone will be broke, so we may not get huge financial support :laughing:

2 Likes
76

I would also love to know MaidSafe’s views on this, and maybe @dirvine can find a moment to speak up…

3 Likes
77

Is this a list of things needed as a part of the proposal? You mean working POCs coded and working? This looks like a substantial part of work already done, so I wonder if anybody would do that before knowing if this is accepted at all. If it would be me, I’d at least need some escrow mechanism in place.

I think David’s views on Native Token are already quite clear, expressed for example in first post on this topic or in bridge topic. He also told multiple times, that he endorses teams other than MaidSafe in working on this:

So I think we could expect substantive design support at least from him. There also were claims about “Pay the developer” and such for a long time. I don’t know if Impossible Futures program is a fulfillment of that, or only a prelude, but perhaps as a community team we could make an appearance to the contest, where all rewards could be paid back to supporters proportionally to the support they gave for the development up front?

There is also a @BambooGarden fund, which although controlled by @maidsafe , seems to be aimed at just what we are talking about here:

Check out the Dev Forum

5 Likes
78

Maidsafe/Autonomi had no problem with us setting up safenetforum-community · GitHub — and why would they? It’s FOSS

Its always easier to get forgiveness later than ask for permission now :slight_smile: Go for it!!!

4 Likes
79

Sorry for the confusion; in my view those would be the key outcomes the proposed work might seek to achieve.

I was suggesting the proposal would include things around the theme in the next list of items in that comment:

Yes, that could be worth considering.

Given there are devs willing to work on something that could be useful to the network, or at least to various projects that can build on the network, I expect it’s an ideal example of the kind of thing the fund was intended for.

2 Likes
80

I’m not sure if the fund remains substantial or if some or all has been spent getting here. David’s response recently to BG about the fund he gifted left me wondering.

7 Likes
81

I guess this is the post:

5 Likes