So let's take a look at the assembly code for our Crowdfund AT:
FUN @block_height get_Block_Timestamp
SLP $decision
FUN @amount get_Current_Balance
BGE $amount $target_amount :funded
FUN @timestamp get_Creation_Timestamp
refund_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @tx_amount get_Amount_for_Tx_in_A
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
SET @funded #0000000000000002
FUN send_to_Address_in_B $tx_amount
JMP :refund_loop
funded:
SET @funded #0000000000000001
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
FUN @timestamp get_Last_Block_Timestamp
end_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
Only 28 lines (25 of which are actual steps and 3 of which are "labels").
So amazingly enough we have built a crowdfunding system that requires only 25 steps of code!
And one of the key things that makes this use case "so efficient" can be found in the first two lines of assembly (which are the first two steps executed after the AT has been created and funds are sent to it).
The first step stores the current block height in a variable (used by the UI so it knows when the crowdfunding actually "started") and the second "key" step puts the AT "to sleep" until the crowdfunding decision time (in blocks) has been reached.
So apart from being executed *once* after creation this AT actually *does nothing* until the time for the decision of whether the target has been reached occurs.
This means it is costing *zero* resources for each node to run after the first two steps until decision time (you couldn't get much more efficient than that).
Show Posts
