OLD: Discussion: Simplicity [one hardcoded generator] vs Complexity [Multiple Generators] for MVP.

[simondlr]

I want to discuss the option of dropping multiple generators for the MVP of Artonomous and just keeping/choosing one hardcoded generator with the option off off-boarding and forking into a multiple generators when the time comes.

The MVP version of Artonomous would be:

• One hardcoded generator [we can have a community voting/choosing system through issues on github].
• One curved bond: ETH <-> SOUL. Art from ETH gets deposited into pool.
• Daily auction.
• No additional staking.

This is quicker to implement, and quicker to test. Less front-end coding, and less UX issues to reason about. It is also much simpler to explain.

Once the multiple generators version goes live, the MVP of Artonomous can be restarted on it. If it's more beneficial and rewarding for the MVP of Artonomous to move its primary generator to the multiple generator artonomous it will slowly do so.

Because we are doing all of this in our spare time, I want to be very cognizant of scope creep.

The trade-off is potentially losing out on a larger network effect. But I think if multiple generators will be successful, then it will happen regardless at some point into the future.

Thoughts?

[simondlr]

We can keep discussion alive on how to eventually implement the full multiple generators version. It's fun problems to solve. So we get best of both. Keep iterating and thinking, but moving getting this out of the door and into the world to test and play with!

[nickreynolds]

What would SOUL be used for if we went with a hardcoded generator?

I actually think that the original plan where a simple staking contract determines the generator is pretty elegant, and maybe some of the issues we came up with are a result of overthinking. For example, I'm not worried about frontend support for rendering when the generator changes as we could accept PRs for frontend support as soon as a generator has some small stake associated with it. Plus, people would be unlikely to stake significant SOUL on a generator before its rendering support is in. Frontend support for the staking contract itself also does not seem like a ton of work.

[nickreynolds]

Also are we actually discussing 3 different possibilities? 1) hardcoded generator 2) staking contract determines single generator 3) multiple simultaneous generators/auctions

[simondlr]

What would SOUL be used for if we went with a hardcoded generator?

It would only be used for dynamically enabling access to funds generated by the art sold [like a single generator in multiple generators, but using SOUL <-> GEN curved bond].

Also are we actually discussing 3 different possibilities?

I haven't considered going back to only one option 2: a single, changing generator because of the complexity involved in having to juggle the rendering.

There's also little incentive in a single, changing generator for people to use their tokens to be staked to a generator. They are undergoing the individual opportunity cost of locking their liquidity for a global good. It presents somewhat of a "tragedy of the commons". We all want a new generator, but no one is willing to stake their tokens. This will likely result in low staking percentages that could cause the generator to change frequently, requiring effort to keep rendering PRs reviewed and merged. This could be a DDOS factor on the bot: if no one is staking (say less than 1%), then just buy 2% of the tokens and keep shifting the generator every single day. There's also still the likelihood as discussed in the spam/forgery discussion that someone can stake in a generator selling copyrighted art.

There are ways to mitigate that. Things like:

1) diluting value of non-staked SOUL tokens when more SOUL are bought. 2) making the generator choice curved bonds themselves, but only allowing the highest staked one to be the current one. This makes it an individually optimal choice to stake towards a generator beyond a globally optimal choice. 3) restricting the change-over to a certain percentage (not a fan of this personally because there's more magic numbers to figure out here).

I'm still in favour of: starting with one hardcoded generator for simplicity's sake. We can always keep iterating from there to different variations. Once this is also published and getting more attention there'll be more people that can join to help us build all the variations.

We can dub it the Artonomous Alpha. The feedback/response can helpful & meaningful too.

[markusbkoch]

I haven't considered going back to [...] a single, changing generator because of the complexity involved in having to juggle the rendering.

Is it technically possible to:

1. require that generators implement a standard JS interface;
2. require that generator scripts be deployed to something like Swarm or IPFS; and
3. for each art piece, have the Artonomous front-end point to the decentralized version of its generator

Wouldn't this make the Artonomous front-end "immune" to changing generators?

[simondlr]

Wouldn't this make the Artonomous front-end "immune" to changing generators?

Not entirely? You could still stake an arbitrary hash of a generator?

We can dub it the Artonomous Alpha.

I still think in the interest of shipping and getting things done, we go for an alpha that is a hardcoded generator. Dubbing it an alpha would also reduce its effect on it capturing network effects too early, knowing that it might be left in the dust for an eventual shifting generator or multi-generator version.

I'd rather keep the ball moving vs getting stuck on the theory phase of solving the issues of the shifting & multi generator [design wise & UX wise].

[markusbkoch]

You could still stake an arbitrary hash of a generator?

Yes, but I meant in the context of a single, changing generator. I might be missing something, but there would be no incentives to staking towards a generator that did not implement the interfaces and generated valuable art, right?

I suppose an antagonistic actor could to do that (at the cost of buying and locking a large chunk of Soul) as an "attack" on Artonomous. But the community would just fork the project, cloning all pre-attack NFTs in a new smart contract and move on, right?

[spengrah]

I had an idea for how to start with a hard-coded generator and still make it (relatively) easy to progress to multi-generator support.

(I actually tried to start a new issue outlining a few options for upgrade design patterns (the architecture decisions we make now will have a big impact down the line on how and what we can make improvements and additions), but github went down for a bit or something and I lost the whole post. I really don't want to type that all up again so I'm just posting the most interesting idea here.)

This idea was inspired by dYdX's approach to upgrades, which modularizes functionality into an immutable base layer on top of which anybody can develop second layer contracts. Users can then transact with whichever second layer contracts they prefer.

• Start with a base layer comprised of the SOUL curved bond contract (this can be upgrade-able via a proxy contract pattern)

• Start with a second layer comprised of the GEN1 curved bond contract, which is in fact a proxy contract with that uses delegatecall() on a second interchangeable contract (classic proxy contract upgrade pattern).

• At first, it would delegatecall the MVP target contract, in which GEN1 is tightly coupled to the SOUL token contract such that users don't actually interact with it at all; all the staking and transferring action with GEN1 and SOUL happens automatically behind the scenes. To the user, it's just like the generator is hard coded.

• But once we decide to support multiple generators, the GEN1 proxy contract would be adjusted to delegatecall() and new target contract, in which GEN1 would be decoupled from SOUL. Users would then have the option to stake their SOUL to GEN1 or to any other GENx (as outlined in #21).

Does this make sense? What do people think?

Note that I haven't thought through how the ERC721 minting would work in the transition, but my sense is that it could be handled.

[simondlr]

I suppose an antagonistic actor could to do that (at the cost of buying and locking a large chunk of Soul) as an "attack" on Artonomous. But the community would just fork the project, cloning all pre-attack NFTs in a new smart contract and move on, right?

Yeah, that's the problem. But it might not even be a lot of SOUL if very little SOUL is currently staked towards the hash of the generator.

I had an idea for how to start with a hard-coded generator and still make it (relatively) easy to progress to multi-generator support.

My gut feeling reading from the description is that this will work, including the auctions.

I think this method even works for potentially changing to a shifting generator, because I think the economics of a shifting generator only makes sense if you also treat the hashes as curved bonds themselves.

Bit late here, so need to 100% confirm if this makes sense.

I'm not 100% sure how governance of upgrade paths would work if we implemented the ability to fork/upgrade into a shifiting or multiple generator version. Who would have that ability? Perhaps the best way to manage it is, is to instead hand it over to fork mechanics, rather than explicit governance.

My gut feeling is still that because this is a pure open source project where all participants are working on this in their spare time, we stick to a hardcoded generator for the MVP. Easier to get done and keeps momentum going.

The free time I have to code on this, I would spend on making this happen. :)

[simondlr]

I moved to making 3 branches, each with their different version. :)