Autonomous Triggers system in SC

[AurelienFT]

Problem

Currently, in the smart contract system you can use send_message to send a message that we will be executed at a given slot.
If you want to execute message with others trigger conditions than a slot you can't.

There is a workaround that exist which consist of sending message each slot and checking the condition each slot but cost an insane amount of gas to just check the condition even if the data we changed didn't even changed.

Solution

We can design a publish/subscribe system where you can subscribe to a channel and when an SC publish on this channel you will be triggered.

Technical design

Three methods should be added in the SC interface:

function subscribe(track_addr: Address, track_channel: String, call_addr: Address, call_func: String, fee: Amount, max_gas: Number)

• track_addr is the address from which SC we accept the trigger to avoid having someone read the SC, find the channel and spam it. Could be potentially an option if you don't want to add this protection. To be discuss.
• track_channel is an identifier to identify the channel you are subscribed to
• call_addr is the address that you want to trigger whenever you receive a trigger
• call_func is the function you want to trigger whenever you receive a trigger
• fee is the number of coins you can pay for gas and for block producer and message publisher
• max_gas is the maximum amount of gas we allow for the execution

function unsubscribe(track_channel: String)

• track_channel is an identifier to identify the channel you are subscribed to

function publish(channel_name: String, data: String)

• channel_name: is an identifier to identify the channel you want to send the message to
• data: is an arbitrary data that will be passed to the function called

Special channels

There are some implicit channel names:

"_datastore" listens to all changes on the datastore of an address, and sends the list of changed datastore entry keys to the callback function as data.
"_balance" listens to changes in balance of the address, and sends the new balance as data
pub cannot be called on those channel names.

What should be the prototype of the function triggered ?

function test(data: String)  {}

• data will be filled by the data passed by the publish method

Coins implications

This functionality should be costly but we need to figure out who will pay and how much ?

Publisher side

Publisher should pay gas for sending the trigger but it should be a constant cost (not dependent of the number of subscribers).

He will get money for the service he provide from the fees of subscribers.

Subscriber side

Each time he receive a message on the channel he need to pay for the gas and a fee for the publisher and block producer.

Notes

The subscriber pay to the publisher so that we can have services on the blockchain that can self-sustain if they are efficient enough. Otherwise the publisher just lose money each time he send and then it limit the use-cases

The subscriber can run out of money in this case the function isn't executed and the publisher don't have the fee from this subscriber.

Spamming limitation

As sending and executing on receiving cost gas and fee for block producer then it's costly to use this system and so it's limited by your money.

Future

In the future we could have a more powerful system with built-in triggers on differents triggers. For example you can directly register to a change in the storage or a balance of someone.
We could also have a query language to have multiple conditions from these built-ins.

Currents problems (updated with answers) :

• What fees should be paid during each execution ?
• Execution sequence in the node

[qdrn]

This would be a killer feature :)

[jcbaillie]

another interesting model of async communication would be the go channels. I think it would be even more powerful (like, making a sc block until some event is received in the channel, etc).

[AurelienFT]

I don't think it's really possible to stop the execution of an SC while executing and I think pub/sub is as powerful as go channels and even more because they are not blocking. Maybe I miss something in go channels I don't know them perfectly so if you have others powerful features I'm really curious to hear so that we can adapt the RFC.

[jcbaillie]

mmm, yes indeed it would not be easy to interrupt a sc: you would have to implement a form of continuation in the vm, it's possible I think, but not trivial. About go channels, I discovered them recently and the fact that they are (optionally) blocking is a big plus in many concurrent applications. Anyway, unless you would see a simple way to implement continuations in wasmer, I don't think go channels are an option indeed. It's just a great concurrency model in my opinion.

[sebastien-forestier]

I dont think we need the publisher contract to explicitly publish / be aware that other contracts are subscribing, in which case this will be much more powerful :)
And I don't think this would be much more work, but let's see

[sebastien-forestier]

I would consider any datastore entry as a "channel", to which you can subscribe, and receive changes

[AurelienFT]

I'm ok with that just removing that having explicit publish message can reduce use cases we could have data store triggers but also custom triggers.

[sebastien-forestier]

I'm ok with that just removing that having explicit publish message can reduce use cases we could have data store triggers but also custom triggers.

I don't think it removes use cases: you can always put your "custom" trigger in your datastore in a data entry called "event_channel" (or anything else) and "publish" to it just by changing the data

[damip]

Here is my take on it:

Sub

sub(address, channel_name, callback_address, callback_function, callback_max_gas, callback_fee, callback_coins)

Calling this registers a listener that will be called when channel_name is triggered for address.

The callback function takes data: String as a parameter.

To de-register, call:
unsub(address, channel_name)

Pub

To publish a message on a channel of the current address (top of call stack):

pub(channel_name, data)

Special channels

There are some implicit channel names:

• "_datastore" listens to all changes on the datastore of an address, and sends the list of changed datastore entry keys to the callback function as data.
• "_balance" listens to changes in balance of the address, and sends the new balance as data

pub cannot be called on those channel names.

Execution sequence

We should move autonomous smart contract execution at the end of a slot, instead of the beginning.
At the end of a slot we have access to the list of LedgerChanges for that slot, as well as the list of messages published by pub.

TODO: define the exact execution sequence

TODO: how to order execution with respect to the current autonomous SCs ? should they be changed and merged into this general behavior ?

TODO: how are the listeners limited/prioritized/dropped, when/how are the fees paid ?

[AurelienFT]

For the fees I was thinking on the subscriber paying and a part goes to the address of the updated data so that we can have services that can self-sustain.

I don't see why we should limit them because if a subscriber isn't called, it shouldn't cost any computation power to the nodes. Just when declaring a new subscriber or receive events the subscriber pay. For the publisher if he want to make a custom publish he pays but otherwise, on balance or datastore changes, no because it don't require more computation power.

For the execution sequence we should speak together I'm not very familiar with the constraints here

[damip]

Subscriber spamming, even if not triggered, would use memory

[AurelienFT]

But register a sub is costly like printing or something else so it will pay memory costs ?

[qdrn]

Questions:
Should we limit the number of subscribers and how ?
When are subscribed functions executed with respect to autonomous SCs ? Ranked by fees ?

[AurelienFT]

I don't see why we should limit them because if a subscriber isn't called, it shouldn't cost any computation power to the nodes (it should only be pub that trigger computation power). Just when declaring a new subscriber or receive events the subscriber pay.

Yes that's a problem. Because in SC autonomous you pay when you send message but here you can receive multiples times and fee market could be higher at a specific execution. I don't have solution right now

[qdrn]

Maybe we don't want to keep subscribers literally for life. Probably depends on how it's implemented as well.

[gregLibert]

This is super cool!
To make it simpler, I propose to replace the pub function by the generate_event.
This way, the originator SC dev doesn't have to do anything to publish something and any event can be subscribed by design.
Do you think that the processing all events as potential pub message will be overwhelming?

[gregLibert]

And I propose that the subscribe part to be handled at the SC level (the one where the event come from), that way:

• the SC will be in control (free subscription or not, public subscription or not...)
• the storage used for the subscription will be the storage of the smart contract
• the fee to emit the event will be paid by the function caller.

[sebastien-forestier]

Here you assume that the developer of the original contract thought/agreed about this and published events. I think it's much more powerful to just subscribe to a change in a datastore entry. That way we have composability even if the original developer of the immutable contract did not think about composability.

[AurelienFT]

I think events are here for the external world to fetch infos from SC and so if we merge this it can become costly etc... I think having both separate is great but definitely having automatic triggers on datastore/balance changes is good

[gregLibert]

Here you assume that the developer of the original contract thought/agreed about this and published events. I think it's much more powerful to just subscribe to a change in a datastore entry. That way we have composability even if the original developer of the immutable contract did not think about composability.

Yes, you right about my assumptions. But by doing what you're proposing, without the agreement of the SC developer, you potentially kill his business model...

[damip]

The point there is that the blockchain is open. If we don't allow things natively, they will be done anyway by centralized bots that monitor the blockchain.

[AurelienFT]

First implementation : #3228