Skip to content

Commit be4c626

Browse files
Merge pull request #7 from mlabs-haskell/technical-additions
new: technical additions
2 parents a612f77 + ee62a08 commit be4c626

File tree

1 file changed

+75
-1
lines changed

1 file changed

+75
-1
lines changed

docs/00-design.md

+75-1
Original file line numberDiff line numberDiff line change
@@ -32,6 +32,7 @@ Open Oracle Protocol_ (aka. Orcfax).
3232
- [Protocol Assumptions](#protocol-assumptions)
3333
- [Additional Proposed Features](#additional-proposed-features)
3434
- [Re-posting GC'ed information](#re-posting-gced-information)
35+
- [Technical Components Involved](#technical-components-involved)
3536
- [Resources](#resources)
3637

3738
## Considered Designs
@@ -97,12 +98,13 @@ feature of _VH_. Given that users can now reference inputs in their transaction
9798
without consuming them, does not allow for the Oracle provider to impose rules
9899
under which the Oracle's information can be consumed. Thus the Oracle provider
99100
loses its financial mechanics and incentive to post information on-chain - to
100-
the detriment of the entire eco-system.
101+
the detriment of the entire ecosystem.
101102

102103
The Orcfax protocol manages to maintain a sustainable funding strategy with the
103104
addition of Reference Inputs, while maintaining a balanced incentive scheme for
104105
both users and oracles providers.
105106

107+
---
106108

107109
### Description
108110

@@ -285,6 +287,78 @@ feasible, but the implications need further exploration.
285287

286288
---
287289

290+
## Technical Components - Type Sketch
291+
292+
293+
1. Oracle Signature
294+
295+
The Oracle's Signature is represented by the public key of the Oracle, which
296+
validates the signing of a transaction with the private key of the Oracle.
297+
298+
```haskell
299+
OracleSignature = PublicKey
300+
```
301+
302+
2. Oracle Token
303+
304+
The Oracle Token is a Cardano Native Token which can only be minted if the
305+
minting transaction is signed by the Oracle's private key - verifiable via the
306+
Oracle's public key. The Oracle can and must be burnt by any consuming
307+
transaction. The Oracle verifies that this token always ends up in an eUTXo
308+
locked under its own pre-defined Oracle Address.
309+
310+
```haskell
311+
SignatureCheck :: SignatureCheck -> SimpleScript
312+
OracleToken :: OracleSignature -> SignatureCheck -> Asset
313+
```
314+
315+
3. Oracle Address
316+
317+
The Oracle Logic is a validation script that ensure the correct handling of the
318+
Oracle Token. Each Oracle instance has its own Script Address where users can
319+
find all of the posted information. The Oracle Address' logic is aware of its
320+
own Oracle's unique Oracle Token's Currency Symbol. The Oracle Address does not
321+
allow the unlocking of eUTXO's without the burning of the Oracle Token.
322+
323+
```haskell
324+
OracleLogic :: OracleToken -> Script
325+
OracleAddress :: OracleLogic -> Address
326+
```
327+
Both the `OracleToken` and the `OracleAddress` can be computed off-chain and
328+
verrified by the Oracle prior to signing. It is of uttermost importance that this
329+
is done correctly by the Oracle to ensure the correct behaviour of the
330+
protocol.
331+
332+
4. Getting the Oracle Signature/ Oracle Token/ Oracle Address
333+
334+
To ensure that clients have access to the correct public-key of an oracle a
335+
naive strategy would be the on-chain presence of the `public-key`, `asset` pair
336+
in an on-chain verifiable format, that also enforces uniqueness. Another method
337+
would be via an off-chain API call that publishes the credentials in a similar
338+
manner to the publishing of information.
339+
340+
---
341+
342+
## Decentralisation
343+
344+
The decentralisation strategy of the protocol relies on the following
345+
assumptions:
346+
347+
1. There are multiple Oracles providing the same information
348+
349+
2. There exists an onchain, script readable representation of the set of Oracles
350+
providing the information.
351+
352+
The decentralisation strategy is inspired by Leonard Lys and Maria
353+
Potop-Butucaru, paper called Distributed Blockchain Price Oracle and adapted to
354+
fit the current design. In summary, a published information could gather many
355+
signatures from a list of oracles, each making note of the veracity of the
356+
to-be-published information. This can be packaged into a separate Oracle that
357+
gathers the information from its list of Oracles. The incentive system is
358+
similar to the one discussed in the paper.
359+
360+
---
361+
288362
## Resources
289363

290364
- CIP 31 - Reference Inputs (<https://cips.cardano.org/cips/cip31/#cddl>).

0 commit comments

Comments
 (0)