I wrote about Autonomous Agent (AA) concept design methodology mainly in terms of functionalities and connecting them using flowcharts as a good way to generate AA design. Naturally, the next question is how to implement these decentralized functionalities using the Oscript language.
Having participated in all AA contests rounds so far, I now have a collection of AAs which I can use as a basis to share techniques I have developed. Hopefully, this will inspire others to use these tested techniques for new autonomous agent. There is also a proposal for these who can reach the end of the article.
In order of simple to comple.
FIFO - First In First Out](https://testnetexplorer.obyte.org/#I4N3UUYUPOJIME5P6WNZ37ZOWHS5QUYV)
Data can be sent continuously by user to get stored onto the Obyte DAG and can be called out again starting from the earliest, once called out the data is removed. In another word, First In First Out. There is a limitation on the size of the data ( at the moment 64 characters ), so for large size data better to store the data somewhere else first and then store a shortened link to the data.
Possible use cases: flood gate type systems that doesn't flow until a threshold is reached, keeping a rotating log for perishable records
To randomly select address to send payment to, the technique used here is to store addresses into integer slots, then using the random_from_seed function to generate an integer that selects a random slot. Need to be a little careful with getting the random integer, as results from AA are suppose to be calculated deterministically for all nodes, this means selecting a good seed string took a little bit of testing and trials. I ended up using a magic salt string combine with input address, timestamps and mci hash to differentiate results from similar AAs running at the same time.
So far I haven't noticed others used this technique yet, but I think the potential for other uses is great when we consider that selecting an individual from a group is likely a common functtionality.
Possible use cases: fairer team player selection, interest based sampling which doesn't require specific information except receiving wallet address
I already wrote two articles on this one. Basically a lookup registry combined with a router, similar to the domain name system. The registry's actual implementation is done by linking an address with a second level logical look up address (using a namespace call "L" + address ) which always points to the latest address. Combine with a ownership declaration and checking technique, this AA allow transfer of address ownership.
I think many dismissed this when it was introduced since it encouraged mutability, but I have since seen the registry concept come up again and again, and is probably going to be a functionality most will use one way or anoother.
Possible use cases: AA app store where app update is required; any property ownership application.
The Time Gate Technique solves the problem of precise date event and fund accumulation mechanism.
First of all, setting a deadline by adding a large secs integer has a serious flaw, as there are leap years and leap seconds, correctly defining an exact date should be done using ISO 8601 date strings.
Combined with "surprise", input funds can continue to get trapped in the gate. Even without a trigger at exactly the deadline (not possible with AA), surprise funnd will correctl release anytime after deadline, and can even reset the gate.
This technique is well suited to any time depend fund locking release functionaality.
Possible use cases: Calendar based repetitive lock up, by day, week or year. Time based investment products
An interesting technique is used call the Rank and Record , this solves the problem of how to rank something with AA when you don't the ability to sort a list, actually you don't even have the ability to loop. The technique is to keep track of the highest ranked item and use compare to keep updating the top ranked item.
By having a headless wallet listening to events from this AA, arbitrary but vetted code running on a person's computer can process data. In another word, turning energy into passive income. The concept is not new, it was inspired by Gridcoin, which uses BOINC (a scientific computation system) which is competitive with world's top 5 supercomputers. One very interesting side effect which others haven't really mentioned so far, is privacy. That is maintained because of isolation of the processor from the public DAG.
Possible use cases: incentivized private and complex distributed computations, utilization of huge number of computing resource, think AWS lambda functions
Quite a bit of moving parts with this AA, as signals are sent out and back in of multiple AAs and user addresses, careful consideration with regards to how much initial bytes is needed to make sure signals further down the process won't bounce and also to return bytes. Two techniques deserve attention here:
Separation of functionality, I have seen most AA are monolithic scripts, but I argue that separation of functionality will be useful not only for code compartmentalization but also cross-AA use.
For example, the choose Red/ Blue address AAs (which by the way are actually just the Select Random Registered Address AA mentioned above), can be used directly in other AA games, in another word the same group can play on different games or applications.
Second technique involves storing and checking turn information, which is done with a integer indexed rounds with time limit and player checking. g.
The technique uses an integer call "round" which keeps adding +1 and using "round" as an index using var[ "round" || "" ] to store data.
Since transaction rate is not fast enough for real-time games, most AA type games will likely be turn based.
Possible use cases: resolution between conflicting interest and views, A-B type testiing.
This entry uses at least these five AAs:
1) Select Random Register Entry2) RedvsBlue (the round tracking part)3) Obot4) Contest Runner (the rank and record part)5) OAAAAA
Interesting fact, a call to Obotic goes thur 9 secondary AAs (the limit is 10). Actually the key mechanism to distribute computation is using a AA loop technique, yes that's right, loops are not allowed in Oscript, but it's possible to do a small loop of 3 iterations by sending payment from primary AA to secondary AA which then calls the primary AA again and repeat (and this can be done 3 times * 3 calls = 9 secondary calls). Part of the technique also requires parsing messages being passed between the AAs.
The AA loop technique allows short repetition
Possible use cases: General distributed and private computing, scientific, mathematical, and big-data analysis, see this article with more details and instructions
--------ill need much improvements before mainnet is operational, I have some ideas especially in user re-engagement and ease of use. Which brings me to the proposal.
With the awards I received from Round3 and Round4, I will be putting out bounties to improve on all my existing and future AA entries.
Tasks will include:
1) Promotion (including graphics design, music, animation, social marketing strategies, etc...)
2) Code Improvement and Documentation
3) Budget Planning and Monetization Strategies
The goal is to be ready for main-net deployment and have a running start with waiting users. Contact me on Obyte Discord or leave me a message here if you're interested or have some ideas.