David's comments from the similar (closed) 181. Also tie together with blog posts and videos on this.
As it currently is, the Zoe guide spends a lot of time explaining what Zoe is, what benefits it provides, but i feel it's not super helpful to design a smart contract
My process when writing the Opera contract was the following:
Design the different interactions/workflow between the different actors with the role hats in a mutually suspicious context
Write the test for the various parties first
and write the contract progressively with the test
Everyone does not need to do like i did, but i feel like, at least, design the roles and interactions is key to properly designing a contract
It took me to understand that keywords refer to roles in the contract (and not issuer names... although the matching in instances is very often 1-1)
A difficulty i had was also with various limitations/idiosyncracies of the platform (cancelObj, limitation of expressivness of offers, having to mint inside the contract and not outside)
I feel like there would be value in capturing this in a document.
It's not clear to me whether this is what "Zoe guide" should be or whether this should be a separate thing
Even though it's been made as easy as possible taking the Zoe design constraints into account
And even with the most optimistic view on the topic, i think i disagree. A Zoe contract is a multi-player game, often with different asymatric roles, and i cannot consider this easy :-p
It's also likely that existing contracts are the easy contracts, so maybe only the hard contracts remain :-)
Tyrosine22
commented
1 year ago
David's comments from the similar (closed) 181. Also tie together with blog posts and videos on this.
As it currently is, the Zoe guide spends a lot of time explaining what Zoe is, what benefits it provides, but i feel it's not super helpful to design a smart contract
My process when writing the Opera contract was the following:
Design the different "roles" in the contract https://github.com/Agoric/agoric-sdk/blob/13b7060c5489642126605068edda56d2ef90e7d6/packages/zoe/src/contracts/operaConcertTicket.js#L7-L19 in AtomicSwap, one role is providing an Asset and another role is providing a Price
Design the different interactions/workflow between the different actors with the role hats in a mutually suspicious context
Write the test for the various parties first and write the contract progressively with the test
Everyone does not need to do like i did, but i feel like, at least, design the roles and interactions is key to properly designing a contract
It took me to understand that keywords refer to roles in the contract (and not issuer names... although the matching in instances is very often 1-1)
A difficulty i had was also with various limitations/idiosyncracies of the platform (cancelObj, limitation of expressivness of offers, having to mint inside the contract and not outside)
I feel like there would be value in capturing this in a document.
It's not clear to me whether this is what "Zoe guide" should be or whether this should be a separate thing
Writing smart contracts that run on Zoe is easy
https://agoric.com/documentation/zoe/guide/#how-to-write-smart-contracts
Even though it's been made as easy as possible taking the Zoe design constraints into account And even with the most optimistic view on the topic, i think i disagree. A Zoe contract is a multi-player game, often with different asymatric roles, and i cannot consider this easy :-p
It's also likely that existing contracts are the easy contracts, so maybe only the hard contracts remain :-)