Pages:
Author

Topic: Understanding the Automated Transaction system (AT) - page 3. (Read 5267 times)

full member
Activity: 137
Merit: 100
AT - Automated Transactions - CIYAM Developer
member
Activity: 112
Merit: 10
full member
Activity: 137
Merit: 100
AT - Automated Transactions - CIYAM Developer
To design an AT properly you need some insight knowledge of how AT is designed to work. I will try to give some hints providing an example for the Lottery case that is currently running on burst platform under the name LuckyAT. The post is rather big and I hope is simple enough to understand.

First of all you need to be aware that each AT is actually an account ( with an address without public key and only the AT can access that account's funds ). The way to "communicate" with the AT is through txs. Sending funds to the AT is achieved with a normal tx.

When the Lottery case is deployed for the first time all the variables are initialized to 0. When the lottery starts for the first time you need to initialize some of the variable properly.

( The full code of the Lottery case can be found here: http://pastebin.com/xiDdMzEG

In the Lottery case the following first lines do that:
Code:
BNZ $payout_time :loop
SET @min_amount #00000005efeb1f00
FUN @payout_time get_Creation_Timestamp
SET @timestamp $payout_time
init:
SET @payout_balance #0000000000000000
SET @tx_info #0000000000002760
FUN @payout_time add_Minutes_to_Timestamp $payout_time $tx_info

The first line does a sanity check to see if the variable payout_time is initialized. If it is not, we are setting the variable min_amount (which is the ticket size to participate to the Lottery) and then we set payout_time to the creation timestamp (which is the "timestamp" of the block the Lottery has been deployed).

NOTE: An important concept in ATs are the "timestamps". Timestamps are constructed using the block height and the order of the tx inside the block. If you want for example to fetch the 3rd tx at block height 15885 then the corresponding timestamp will be (15885)(3). The best way to think timestamps is the combination of two integers, one for the block height and one for the tx. The Creation timestamp always uses 0 for the second part f.e (blockHeight)(0).

As stated also in www.ciyam.org/at/at_api.html : "timestamp" does not mean a real timestamp but instead is an artificial timestamp that includes two parts. The first part is a block height (32 bits) with the second part being the number of the transaction if applicable (also 32 bits and zero if not applicable).

The third line is copying payout_time to timestamp.

The 5th line is "labelling" the following code as a branch point where you can "jump" later if needed.
The 6th and 7th lines are initializing payout_balance ( which is the total amount the lottery gathered as winnings for the winner) and tx_info respectively. Tx_info will be used as input to the API call add_Minutes_to_Timestamp along with payout_time and what actually this line does is:
payout_time = payout_time + tx_info
This way the lottery is aware after which block can send the prize to the winner and restart.

The next lines are the following:
Code:
loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BNZ $tx_info :process_tx
FIN

Here the lottery fetches the first tx (if any) after the provided timestamp. If there is a tx ( FUN @tx_info check_A_Is_Zero ) then we proceed processing the tx else the AT stops and sets the program counter (pc) to pcs (FIN op code) ( pcs is zero at that point ) .
Setting the pc to 0 makes the AT to start from the first line ( BNZ $payout_time :loop ) the next time it will run.
Also stopping the AT using the FIN op code will "freeze" the AT until the ATs account balance changes ( f.e. until someone sends funds to the AT ). If you don’t want at this point to freeze the AT, you could change the FIN with SLP op code which will make the AT to "sleep" for just one block. ( That does not mean always that the AT will run on next block, as the block might be full with other ATs which have higher priority to run ).

If there is a tx then the Lottery continues with:
Code:
process_tx:
FUN @tx_time get_Timestamp_for_Tx_in_A
BLT $tx_time $payout_time :get_info_amount
JMP :payout

Here we get the timestamp of the tx and we check if that timestamp is less than the payout_time timestamp. If it is, we proceed fetching more info for that tx ( :get_info_amount ) else is time to pay the winner the total amount gathered ( JMP :payout ).

Code:
get_info_amount:
FUN @tx_amount get_Amount_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
FUN @tx_info get_B1
FUN B_to_Address_of_Creator
FUN @creator get_B1
BEQ $creator $tx_info :bootstrap
FUN @tx_info get_Type_for_Tx_in_A
BNZ $tx_info :skip
BEQ $tx_amount $min_amount :get_ticket
JMP :refund

Note: The Lucky AT has been programmed to not draw a ticket for funds received from the Creator's Address. This way the creator can send funds to the AT to increase the prize without participating in the draw.

The above piece of code fetches the amount of the tx, the address of the sender and the address of the creator. If these two addresses are equal we jump to :bootstrap (see above note), else we fetch the type of the tx ( 0-> normal tx, 1-> message tx). If the tx is not a message tx, we check if the amount of the tx is equal to the ticket amount. If it is we proceed drawing a ticket for that tx else we proceed on refunding that tx.

Note about the amounts: When you create an AT you set a field called minimum activation account. That amount is the minimum account required to process the tx. All the API calls that return amounts are deducting that minimum activation account ( f.e if minActivationAmount is set to 10 coins and you send a tx of 250 coins, the amount the AT will see is 240).

 Moving forward we see:
 
Code:
 get_ticket:
FUN @tx_info get_Ticket_Id_for_Tx_in_A
FIZ $tx_info
FUN B_to_Address_of_Tx_in_A
FUN set_A1 $tx_info
FUN send_A_to_Address_in_B
ADD @payout_balance $min_amount
BLE $tx_info $best_ticket :skip
SET @best_ticket $tx_info
FUN @best_account get_B1

Here we draw a ticket for that tx and if the ticket is not zero we send a message with the ticket value to the sender of the tx. After that we add the amount of the tx to the payout_balance and we check if the ticket we have draw is greater than the current best_ticket. (Note: The highest ticket wins). If the ticket we have picked is greater, we store the ticket value to best_ticket and the senders account to best_account, else we jump to skip.

Note: the API call get_Ticket_Id_for_Tx_in_A is making the AT to freeze at that point until the ticket is "ready" assuring the ticket is random ( a ticket is ready after 15 blocks from the block the tx belongs, f.e. if you make a tx at block height 14500 then the ticket will be ready at block 14515 and the AT freezes until then).

Code:
skip:
SET @timestamp $tx_time
JMP :loop

Here we set the timestamp to the tx's timestamp we just processed and jump to loop where we continue fetching txs after that timestamp.

Code:
bootstrap:
ADD @payout_balance $tx_amount
JMP :skip

Here we increase the prize ( payout_balance ) when the creator sends funds to the Lottery.

Code:
payout:
BZR $payout_balance :empty
BZR $best_ticket :empty
FUN set_B1 $best_account
FUN @block_timestamp get_Block_Timestamp
BEQ $block_timestamp $payout_time :pay_all_at_amount
FUN send_to_Address_in_B $payout_balance
JMP :finish_payout
pay_all_at_amount:
FUN send_All_to_Address_in_B
JMP :finish_payout

The above code checks that we have a winner and if we have a winner we pay him either the total ATs account or the payout_balance.

NOTE: Sometimes the AT might have more or less amount than the one it has gathered from tickets. When the ATs amount is greater it means that the processing fees were less than the "minimum activation amount's" gathered from tx's. If the ATs amount is less then the "min activation amount" was set "wrongly" and the processing of the tx's are more costly. Sometimes is difficult or impossible to have a constant min activation amount (f.e if a transaction is greater than the amount needed to participate, the tx will be refunded, thus it will consume more fees. If the tx is equal to the ticket amount then there are no fees for refunding that tx ).

Code:
empty:
SET @timestamp $tx_time
JMP :init

If there is no winner on the previous round ( none txs were sent to the Lottery) then we proceed with initialization of the variables.

Code:
refund:
FUN B_to_Address_of_Tx_in_A
BLE $tx_amount $min_amount :refund_less
SUB @tx_amount $min_amount
FUN send_to_Address_in_B $tx_amount
JMP :get_ticket
refund_less:
FUN send_to_Address_in_B $tx_amount
JMP :skip

Here the refunding takes place. There are 2 possibilities. Either the amount of the tx is greater than the ticket amount or less. If the txs amount is greater then we refund the difference ( tx_amount - min_amount) and then we draw a ticket for that tx, or we refund the total amount of the tx.

Code:
finish_payout:
SET @timestamp $payout_time
SET @best_ticket #0000000000000000
SET @best_account #0000000000000000
JMP :init

After paying the winner we set the timestamp to payout_time and we initialize best_ticket and best_account to 0 and we continue by jumping back to init.

member
Activity: 112
Merit: 10
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
can you explain in a few words...
how AT could be use to implement a simple gambling like lottery or dice game??

Our very first "use case" was a Lottery (which runs on Burst with a new draw once per week) so the raw assembly code for it is as follows:

Code:
00000000* BNZ $00000000 :0000004c
00000006  SET @00000001 #0000002e90edd000
00000013  FUN @00000000 0x0301
0000001a  SET @00000002 $00000000
00000023  SET @00000003 #0000000000000000
00000030  SET @00000004 #0000000000002760
0000003d  FUN @00000000 0x0406 $00000000 $00000004
0000004c  FUN 0x0304 $00000002
00000053  FUN @00000004 0x0125
0000005a  BNZ $00000004 :00000061
00000060  FIN
00000061  FUN @00000005 0x0307
00000068  BLT $00000005 $00000000 :00000077
00000072  JMP :00000110
00000077  FUN @00000006 0x0306
0000007e  FUN 0x030a
00000081  FUN @00000004 0x0104
00000088  FUN 0x030b
0000008b  FUN @00000007 0x0104
00000092  BEQ $00000007 $00000004 :00000102
0000009c  FUN @00000004 0x0305
000000a3  BNZ $00000004 :000000f4
000000a9  BEQ $00000006 $00000001 :000000b8
000000b3  JMP :00000156
000000b8  FUN @00000004 0x0308
000000bf  FIZ $00000004
000000c4  FUN 0x030a
000000c7  FUN 0x0110 $00000004
000000ce  FUN 0x0405
000000d1  ADD @00000003 $00000001
000000da  BLE $00000004 $00000008 :000000f4
000000e4  SET @00000008 $00000004
000000ed  FUN @00000009 0x0104
000000f4  SET @00000002 $00000005
000000fd  JMP :0000004c
00000102  ADD @00000003 $00000006
0000010b  JMP :000000f4
00000110  BZR $00000003 :00000148
00000116  BZR $00000008 :00000148
0000011c  FUN 0x0116 $00000009
00000123  FUN @0000000a 0x0300
0000012a  BEQ $0000000a $00000000 :00000140
00000134  FUN 0x0402 $00000003
0000013b  JMP :00000184
00000140  FUN 0x0403
00000143  JMP :00000184
00000148  SET @00000002 $00000005
00000151  JMP :00000023
00000156  FUN 0x030a
00000159  BLE $00000006 $00000001 :00000178
00000163  SUB @00000006 $00000001
0000016c  FUN 0x0402 $00000006
00000173  JMP :000000b8
00000178  FUN 0x0402 $00000006
0000017f  JMP :000000f4
00000184  SET @00000002 $00000000
0000018d  SET @00000008 #0000000000000000
0000019a  SET @00000009 #0000000000000000
000001a7  JMP :00000023

Perhaps @vbcs might post a nicer version for you that was created using AT Assembler (which has variable *names* and *labels* rather than just addresses as yes I realise that the above is more than a little hard to decipher).

We are working on the idea of some quicker random games of chance and will be sure to let people know when we have a simple example that they can study (we might perhaps make a simple "highest random value wins" for two consecutive players).

One limitation that AT hosts do have is how quickly they can generate "random" data (on Burst that is currently set at 14 blocks from memory) so you could have a dice kind of game but it won't be "instant" (the same AT could work much faster on a blockchain that can produce entropy quicker).
member
Activity: 112
Merit: 10
In order to help explain how AT works and to help anyone trying to create ATs who mostly use this forum for information I have created this topic.

*** mods please note that AT has been designed to work on any blockchain so please do not move this into the alts section ***

The current documentation for AT can be found here: http://ciyam.org/at but it is highly technical (we do intend to provide some simpler documentation as we progress).

So if you have any questions about AT (what it can and can't do, how does it work, etc.) please ask away.

P.S. I've made this topic self-moderated as unfortunately I am currently being followed by trolls in every new topic I create (but I will only be removing off-topic or troll posts).


hi CIYAM!!!

can you explain in a few words...
how AT could be use to implement a simple gambling like lottery or dice game??

thanks!!!
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
For those keen enough to want to create an AT for themselves an AT Assembler has been created (written in Scala) which you can find here: https://github.com/BurstProject/ATAssembler (it is what has been used to create the AT use cases that have been released with Burst).

Although creating ATs in assembly language is clearly no easy thing we include HTML with our AT use cases that actually mean you can create your own instant clone without having to know or care about any code (just fill in a simple form and click a button).

We are still yet to formalise a UI specification system but we hope to have that worked out soon so we can extend our tools to be able to make it very easy for people to create portable ATs with a nice looking UI with the minimum of effort.
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
Although AT is currently only tied to Burst I think that this link is still worth sharing: https://bitcointalksearch.org/topic/m.10397472 as we have created a decentralised Crowfunding system (with no 684 pledger limit such as Lighthouse has).
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
How AT can be used with Bitcoin?

What is needed to be done?

AT could be used with Bitcoin (assuming the core devs decide to implement it) and the way that could be done is described here: http://ciyam.org/at/at_script.html (a general technical description of how Bitcoin Script could be changed to support AT with the addition of just one new op code).

It would of course be best for this to be done on a Bitcoin clone first which is why I created a 20 BTC bounty for just this: https://bitcointalksearch.org/topic/20-btc-bounty-for-first-at-atomic-cross-chain-transfer-with-script-clone-826263 (we have had some interest in the bounty but no-one has yet "bitten the bullet" and actually started implementing it AFAIA).

I'd expect that the core devs would want to see how it goes on a Bitcoin clone (maybe several) for quite a while before they would consider whether or not they would want to add the functionality to Bitcoin itself (and that is a perfectly reasonable attitude to have).
sr. member
Activity: 351
Merit: 250
How  AT can be used with Bitcoin?

What is needed to be done?
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
In order to help explain how AT works and to help anyone trying to create ATs who mostly use this forum for information I have created this topic.

*** mods please note that AT has been designed to work on any blockchain so please do not move this into the alts section ***

The current documentation for AT can be found here: http://ciyam.org/at but it is highly technical (we do intend to provide some simpler documentation as we progress).

So if you have any questions about AT (what it can and can't do, how does it work, etc.) please ask away.

P.S. I've made this topic self-moderated as unfortunately I am currently being followed by trolls in every new topic I create (but I will only be removing off-topic or troll posts).
Pages:
Jump to: