I was reviewing the Marlowe paper, mostly focusing on the integration part.
Basically how to have external real time events trigger the Marlowe Smart Contracts. It’s nice to have native support for the Blockchain events, but this would cover a very small percentage of the desired Use Cases along the vision being “a financial DSL to fundamentally reinvent wall street” (Tweet from Charles).
Marlowe is using the terms “Observation” which is based on a set of “Observables”, that will decide once such a Smart Contract should be triggered.
It also suggests that these “Observables” will be provided by trusted Oracles to Marlowe contracts.
I believe this is very “grey” explanation at the moment and technically has a lot of questions & issues.
A - First of all we should allow for complex Observations, which means our Observation would be described following a Complex Event Pattern (see “Complex Event Processing” to understand capability), having time-windows, logical expression of events occurrences or non-occurrences, event queries, etc.
B - We should also allow each party who transacts / participates within a Marlowe contract to freely decide on whichever Oracles they trust and nominate to the contract along with an agreement on the consensus approach for these “duplicate” events from various sources. Individual Observables should be allowed to come from various Oracles and for the very same Observable we should allow multiple Oracles to provide the event feed.
C - We should not push down real time event streams (the state of all the Observables) to the Blockchain simply for performance & efficiency reasons, it simply does’t belong there.
The above constraints simply do not fit with the described integration approach having an Oracle feeding everything we need to the Marlowe contract.
Take a dummy example, “Trigger contract ABC once latest on the 5th working day of each month, but anytime following the 1st working day whenever the USD/EUR exchange rate is below X and Google share price is above Y and ADA/BTC is within range Z and … “ We need a trust layer for such rules, we can’t just say & rely on Oracle ABC to tell us once such an Observations has happened. Oracles might even be specific to certain event types and not support all we need.
I believe we need an extra layer (let’s call it Smart Rules layer) on top of the Cardano Computational Layer (CCL), which would consent on such events and trigger the corresponding Smart Contracts. Basically the observation would happen within the Smart Rules layer (not in a single appointed trusted Oracle, neither in the CCL Smart Contract Layer, but in a mediating layer between).
So what would be defined within a Smart Rule?
Within a Smart Rule parties would agree on the Complex Event Pattern, on a set of external Event Providers / Oracles, on the various Event Consenting Mechanisms, the Smart Contracts to trigger, Governance Policies to manage its lifecycle and provide fuel to temporary cover costs. The Smart Rule would pay a set of the decentralized nodes for being included in their high performance rule engine, operate the consensus protocol, allow the nodes to pay & subscribe to the event streams via the Oracles / Event Providers and pay for the Smart Contract execution.
You would use high performance decentralized Apache Flink / Apache Spark / Apache Storm like technology for the Smart Rules Layer. Apply principles of Complex Event Processing. Enrich with various Consensus Algorithms. Provide a Blockchain backbone as a shared persistence layer.
As a summary:
Smart Contracts define “What?” Logic to execute, but we need Smart Rules to mediate “When?”, under which special circumstances must such an execution take place. These circumstances should depend on state beyond the Blockchain, on external real time complex events.
Real Time Financial Market Events, IoT Sensor Events, Sports Events, News Events, DateTime Scheduler Events, etc. should be all a basis for building complex event patterns that would trigger Smart Contracts with the same security guarantees and other qualities we have for the Blockchain. We would not rely the Observation on a single Oracle, but rather rely on a set of redundant Oracles to provide the event streams for the Observables, without exposing to them any details about the Observation or the Marlowe contract(s) to be executed. This is a completely different strategy.
Please let me know what you think? Maybe there is another sufficient integration approach for Marlowe I just didn’t clearly get on a first read. Nevertheless I have the feeling there is a need for a Smart Rules concept & layer.
See some Event Processing Capabilities below being an indicative example from Tibco Business Events & StreamBase commercial products comparing “Event Patterns”, “State Machines / Rules” and “Continuous Queries”. The Observation feature of Marlowe should allow for such mature definitions if the goal is to reinvent The Wall Street.