spengrah
commented
6 years ago I like the concept of built-in support for multiple generators. Maintaining network effects while allowing for additional experimentation will keep everybody happy. In other words, if we can achieve variety and experimentation without splintering the community with a fork, that's a good thing.
That said, if we want to keep things simple and focus just on the initial problem of low generator staking, a potential solution would be to impose a cost to bystanders to lower the effective opportunity cost associated with staking. This could be accomplished with inflation, e.g. when new ETH enters the pool a new SOUL token is minted and for each staked SOUL token and granted proportionately to each staker. Bystanders' SOUL token holdings are thus devalued.
While we're in the mood for adding scope (:stuck_out_tongue:), an additional possibility for Artonomous: add a way to create new feature bounties funded from the ETH pool (or maybe the SOUL pool in the case of multi-generator support). Here I'm primarily thinking of a bounty for generator front-end work in the case that the multi-generator approach is selected. After all, the set of people with great artistic vision doesn't perfectly overlap with the set of people with the requisite coding skillz. (I'll create a separate issue for this if there's interest but I'm just spitballing here).
simondlr
Hey everyone.
Here's an open discussion. I'm not 100% convinced that the generator (and its hash) be chosen simply by the highest amount of staked soul tokens. The current approach outlined in #3 is the following:
The issue with this is:
1) The incentive to take on the opportunity to cost to stake towards a new hash needs to be such that the belief is in doing so, will generate enough new income for the artist such that its worth the opportunity cost. This opportunity cost is the cost of keeping one's own soul tokens illiquid. Other participants gain from this as well and thus the opportunity cost might be quite high ("Why would I stake to change the hash if everyone else can just claim rewards for it whilst I undertake the cost for doing so?").
2) Low staking will mean that the generator hash could change quite often. This makes it hard to implement the generator into the front-end fast enough if the hash does change. Adding a threshold is just arbitrary and hard to determine what would be meaningful in this context.
3) A generator hash can be chosen that can't actually be implemented. This can break the autonomous artist. Due to the low potential threshold in doing this, it could be griefed quite easily or even accidentally.
The goal of this discussion is to determine how we approach generators in general with artonomous. There's several variants that can be taken that differ in complexity.
The core choices are:
1) Hard-code to one generator OR 2) Allow multiple generators at the same time (with its own incentive games).
1) Remove the ability to upgrade/change the generator.
This is purely for simplicity reasons. A generator is chosen before hand and is hardcoded for this specific autonomous artist. If a different generator will generate and sell more art into the future, then one can simply fork this project and create a unique curved bond for that specific art bot.
The gains in simplicity of implementation & user experience design though dilutes the value prop of a self-improving artist. It also loses network effects around this specific autonomous artist.
2) Allow any amounts of generators.
If we assume that multiple generators will come to exist if this project is successful (forking, remixing, etc), then we might as well aim to allow multiple generators from the start. Instead of having multiple artists with their own curved bonds, we aim to build it such that there's a network effect around multiple generators towards one autonomous artist.
Thus the second options entails that anyone can kickstart a generator at any point in time, making it "sentient". (ht @nieldlr for that terminology). Thus: multiple generators will co-exist concurrently, with multiple auctions happening simultaneously. Each generator will have its own 24 hour lifecycle.
To kickstart a generator, one has to stake soul tokens to a specific generator's curved bond. The ETH paid towards a specific generator's art goes to towards minting new SOUL tokens, which is then deposited into that specific generator's curved bond. Thus, it possible to essentially earn more SOUL tokens by participating in the game of curating good generators.
Here's an example of staking:
ETH <-> SOUL (on a curved bond). SOUL <-> [generator] (on a curved bond).
ETH coming from artwork sold, buys SOUL tokens and deposits the SOUL tokens into that generator's curved bond. New generator tokens are NOT minted when the new SOUL tokens are deposited into the generator's bond.
The success of a generator is thus also contingent on the generator creator adding the ability to view the artwork viewer to a front-end. If they don't, then the generator won't be successful. This then also does not block the autonomous artist in general.
The downside of this implementation is it complexity, both in terms of smart contract designs (likely have to include ERC20/777 Bancor for generator curved bonds) & user experience. It will also dilute the initial value of this experiment [many more art pieces and another additional staking game].
This latter implementation thus solves the issues:
1) Incentive to stake towards generator hashes. 2) Staking to generator hashes will be contingent to whomever wants to play the game of curating generators. 3) One doesn't have to update the front-end every single time a new generator is chosen. It's not time-dependent. It just has to happen eventually. Third-party viewers can also choose to do this themselves, rather than going through a specific website.
Other options?
Subsequent forks of artonomous can become more complex and could even allow people to fork into its children by burning soul tokens across to the new artists (eg: https://medium.com/@simondlr/burning-bridges-to-greener-grass-incentivizing-tokenized-forking-393c69dfecab).
Considerations
I feel it's important to design this in such a way that there's no magic numbers involved: eg choosing a hardcoded fee or choosing a hardcoded percentage threshold. These are unknown at this stage, so would rather opt for some more continuous, market-based options.
If the autonomous artist works, we'll see people forking this anyway and applying many more generators, so might as well aim to keep the generator network effect under one engine.
Addendum
A second order benefit for multiple generators is that because a specific generator isn't required for the lifeblood of the whole autonomous artist, one can also experiment with allowing the generator creators to earn from a successful generator. In other words, each generator is dependent on it also setting a beneficiary and a fee.
An artwork would thus be combined of 4 components:
[blockhash, generator_hash, generator_beneficiary, generator_percentage_fee]