-
Notifications
You must be signed in to change notification settings - Fork 44
SCP-4387 Re organize isabelle semantic types to become literal programming #134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
ff9b2ee
a77d83a
0d1a15b
1c001cd
7668ce1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| (*<*) | ||
| \<comment> \<open>This module defines the types we abstract from Blockchain specific implementation\<close> | ||
| theory BlockchainTypes | ||
| imports Main Util.Serialisation | ||
| begin | ||
| (*>*) | ||
|
|
||
| section \<open>Blockchain agnostic \label{sec:blockchain-agnostic}\<close> | ||
|
|
||
| text \<open> | ||
| Marlowe is currently implemented on the Cardano Blockchain, but it is designed to be Blockchain agnostic. | ||
| \<close> | ||
|
|
||
| text \<open> | ||
| Programs written in languages like Java and Python can be run on different architectures, like amd64 or arm64, because they have | ||
| interpreters and runtimes for them. In the same way, the Marlowe interpreter could be implemented to run on other blockchains, | ||
| like Ethereum, Solana for example. | ||
| \<close> | ||
|
|
||
| text \<open> | ||
| We make the following assumptions on the underlying Blockchain that allow Marlowe Semantics to serve | ||
| as a common abstraction: | ||
| \<close> | ||
|
|
||
| text \<open> | ||
| In order to define the different \<^term>\<open>Token\<close>s that are used as currency in the participants accounts | ||
| \secref{sec:internal-accounts}, deposits, and payments, | ||
| we need to be able to express a \<^term>\<open>TokenName\<close> and \<^term>\<open>CurrencySymbol\<close>. | ||
| \<close> | ||
| type_synonym TokenName = ByteString | ||
| type_synonym CurrencySymbol = ByteString | ||
|
|
||
|
|
||
| text \<open>To define a fixed participant in the contract \secref{sec:participants-roles-and-addresses} | ||
| and to make payouts to them, we need to express an \<^term>\<open>Address\<close>.\<close> | ||
| type_synonym Address = ByteString | ||
|
|
||
| text \<open>In the context of this specification, these string types are opaque, and we don't enforce | ||
| a particular encoding or format.\<close> | ||
|
|
||
| text \<open>The \<^term>\<open>Timeout\<close>s that prevent us from waiting forever for external \<^term>\<open>Input\<close>s are represented | ||
| by the number of milliseconds from the Unix Epoch \<^footnote>\<open>January 1st, 1970 at 00:00:00 UTC\<close>. \<close> | ||
| type_synonym POSIXTime = int | ||
|
|
||
| type_synonym Timeout = POSIXTime | ||
|
|
||
| text \<open>The \<^term>\<open>TimeInterval\<close> that defines the validity of a transaction is a tuple of exclusive start | ||
| and end time. \<close> | ||
| \<comment> \<open>TODO: Check if exclusive or inclusive\<close> | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it is meant to be inclusive on both sides. Not sure about ledger or plutus, which last time I heard was inclusive on min and exclusive on max
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bwbush do you know the answer to this? |
||
| type_synonym TimeInterval = "POSIXTime \<times> POSIXTime" | ||
|
|
||
| (*<*) | ||
| end | ||
| (*>*) | ||
Uh oh!
There was an error while loading. Please reload this page.