Sketch of Plutus chain emulator #124
Conversation
|
I mad a number of changes from the draft, but I think they're all simplifications. |
| -- TODO | ||
| class WalletAPI m where | ||
| submitTxn :: Txn -> m () | ||
| handleNotifications :: [Notification] -> m () |
There was a problem hiding this comment.
Is this to allow the Plutus client (user of wallet API) to register for notifications? If so then I think it should be possible to register a callback
There was a problem hiding this comment.
No, this is supposed to be the function that gets called on the wallet when some notifications come in for it. At which point it should add any appropriate blocks to its internal state, trigger reactions, etc.
I didn't write in any of the functions for registering handlers etc, but obviously those should be there.
There was a problem hiding this comment.
I see, I thought that we would eventually have two implementations of WalletAPI, namely the mock wallet API and the "real" wallet API. In the real one it wouldn't make much sense to notify the wallet like this (because it would receive its notifications from the core node, which would not be visible to the client).
There was a problem hiding this comment.
Maybe remove it from the class and write
handleNotifications :: MonadEmulator m => [Notification] -> m ()
handleNotifications = ...
There was a problem hiding this comment.
Ah I see. So the version here should just work on the emulated wallet.
| -- take place. | ||
| data Event n a where | ||
| -- these need the coordination code to tell us what to do | ||
| WalletAction :: Agent -> n () -> Event n [Txn] |
There was a problem hiding this comment.
I think we should add another parameter m for the wallet interactions that the client code is allowed to do. Or maybe even
WalletAction :: forall m. WalletAPI m => Agent -> m () -> Event n [Txn]
By constraining it like that, and removing handleNotifications from WalletAPI we ensure that any code we write as a WalletAction can be run against the real wallet later on.
There was a problem hiding this comment.
That's exactly what n is, no? Just without the class constraint here.
There was a problem hiding this comment.
That's exactly what n is, no?
Yes, and in this place n is not right. Currently I can write
trace :: Trace ()
trace = Op.singleton $ WalletAction (Agent 1) (handleNotifications [BlockHeight 100])
Which does not make sense to me. And the two changes I proposed would ensure that this doesn't type check anymore (there are other changes you can make to achieve the same goal, which I would also be happy with :) )
The reason why I think it shouldn't type check is that inside WalletAction we want to write code that is agnostic of the wallet API implementation, so it could be executed against a real wallet also. And in that context handleNotifications does not make sense because the real wallet gets its blockchain notifications from a core node, not from the plutus client.
There was a problem hiding this comment.
Yes I 100% agree that handleNotifications should not be in WalletApi, but I don't think we need to change Event.
| -- TODO | ||
| class WalletAPI m where | ||
| submitTxn :: Txn -> m () | ||
| handleNotifications :: [Notification] -> m () |
There was a problem hiding this comment.
Maybe remove it from the class and write
handleNotifications :: MonadEmulator m => [Notification] -> m ()
handleNotifications = ...
| data Txn = Txn Int | ||
| deriving (Show, Eq, Ord) | ||
| -- each agent has its own wallet state | ||
| data Agent = Agent Int |
There was a problem hiding this comment.
Should we call this Wallet?
| -- Basic types (should be replaced by "real" types later) | ||
|
|
||
| -- don’t care what these are, some data to allow typeclasses | ||
| data Txn = Txn Int |
There was a problem hiding this comment.
Maybe call it Tx? This seems to be the standard abbrev and later you use TxPool.
| -- these are always responded to in a routine way, check triggers, update wallet state etc. | ||
| WalletRecvNotification :: Agent -> [Notification] -> Event n [Txn] | ||
| BlockchainActions :: Event n Block | ||
| Assertion :: Assertion -> Event n () |
There was a problem hiding this comment.
Assertions as events seems strange.
There was a problem hiding this comment.
They are events from the emulator's point of view - they are things that we want to occur at a particular point in time in the event stream.
| WalletAction :: Agent -> n () -> Event n [Txn] | ||
| -- these are always responded to in a routine way, check triggers, update wallet state etc. | ||
| WalletRecvNotification :: Agent -> [Notification] -> Event n [Txn] | ||
| BlockchainActions :: Event n Block |
There was a problem hiding this comment.
Aren't blockchain actions the same as notifications (further up)? Or what other actions do you imagine the blockchain can take that are relevant for us here?
There was a problem hiding this comment.
Blockchain actions reflect actions that actually change the chain state. Notifications represent that information reaching wallets. Which is a distinct event that can happen later. Also "blockchain actions" here is an event that bundles up a bunch of core-node stuff that could maybe be distinct.
| let block = validated | ||
| put emState { | ||
| emChain = block : emChain emState, | ||
| emFailedTxPool = failed ++ emFailedTxPool emState |
There was a problem hiding this comment.
Why do you keep failed transactions? For comparison in tests? (The real blockchain just drops them on the floor.)
There was a problem hiding this comment.
Yes, exactly (there's a brief note on FailedTxn). You might want to assert that a txn failed to validate - you could equate that with saying it's not in the chain or pool, but it seems helpful to have a reason too.
Actually, I think that's premature design, let's drop it for now.
|
Comments addressed. |
michaelpj
force-pushed
the
imp/emulator-sketch
branch
from
e7a9824 to
dff4de9
Compare
This is an actually-working version of the types @j-mueller and I sketched out yesterday.
I implemented the tiniest part of the emulated wallet (submitting a fake transaction), so there is an actual example you can run! You can load up the file in GHCI and then run
runState (runExceptT (process trace)) emptyEmulatorState.