As some of you may have noticed, we expect PIBD to be implemented on the rust node in the next few months. I believe it’s time to talk what we believe is the road forward after that. An overview of the possible path forward would be:
PIBD and making sure the IBD works well for all nodes
a GUI wallet that uses rust node APIs
an open source grin explorer
safe-cancel and early-payment-proofs
unified transaction flow (setup → sign → sign)
more robust “exchange grade” wallet backend
work to bolster testnet by adding nodes and miners
So the plan is to focus on making the wallet experience better for the user after IBD is sorted out. Any and all changes that require an RFC will go through this standard process. This means we’ll need to push some RFCs forward for these ideas to come to life.
The above goals are not set in stone. Priorities may shift if we find other stuff more important.
I think PIBD is a natural way to sync to a Mimblewimble like chain. The current sync treats the whole dataset as a single piece that is downloaded and validated. PIBD allows for a construction of the dataset by obtaining multiple smaller pieces, possibly from different peers.
Do you maybe know the order in which these things will be implemented?
Is new gui meant as port of grin++ to rust implementation (so to be interchangeable, although that’s hard to maintain probably) or a new gui (if a new gui who will develop it)?
PIBD will clearly be first. I don’t know about the others. I do think there’s some overlap e.g. setup -> sign -> sign would get even simpler if we had early payment proofs because then it’s no longer a question of which proof you make and at which step, you simply produce an early proof like seen here in the pseudo.
Not sure what you mean by “port of grin++”. It will likely be new code that uses grin-wallet as the backend. Anything else is just guessing at this point.
I take it this means that those of us who would like to run a node for the benefit of the community can better help by running on testnet now. I assume basic proficiency to build and run is sufficient but if only more knowledgeable operators are needed let me know.
For mining does testnet need trivial cpu, GPU, or mini ASIC power to be helpful?
I think the project stands in a strong position post 5.0 HF regarding api functionality and wallet use; some minor adjustments needed of which developers have met with required adjustment; it’s clear developers have a thorough understanding of how users are interacting with the api and how these interactions can be further optimized while expanding functionality. Overlooking the list here I appreciate your view of horizon and insight- here’s my opinion:
PIBD being a significant upgrade to IBD- I would like to see this work segway into *Preventing chain corruption perhaps by way of optimizing the txhashet and moving nodes over to a new txhashet.
Unified-TX-flow - I like the work you did here(Grin TX construction · GitHub) it’s obviously well thought out and solves some of the confusion while keeping intact the mechanisms I appreciate in itxs. I hope this continues to be a priority- (further optimizing api design and making adjustments based on the feedback/ particular txsMethod)
Rustlang GUI; I’m not sure the oc needs to be invested in maintaining a Rustlang gui as the community has already developed ironbelly and niffler. However, I do see ensuring stability and access to working tools as a core function of the project. But how does one maintain and make available these tools if they are outside of mw repos? It’s an unfortunate reality that sometimes projects are no longer updated for whatever reason- as such I would like to see a minimal GUI that falls into the responsibility of the project core. I’d like to not reinvent the wheel, nor waste valuable resources on doing so; as such it would seem an option to extend an invitation to the already community developed Rustlang gui(@i1skn , @xiaojay) to join the mw repos (if acceptable to parties involved) if not acceptable then I would like to see the oc move forward developing a minimal gui in the mw repos to ensure that as the api’s develop a gui will be updated with it’s new functions (user friendly implementation because not everyone is comfortable with terminal)
safe-cancel and early-payment-proofs - yes and yes please
'exchange grade wallet - I’d like to see api design incorporated for both ‘user grade’ and ‘exchange grade’- as far as developer priority/availability I see getting PIBD situated on the already built api functions essential, but I do hope that after these refinements then ‘exchange grade’ functions can be built. P2P txs along with online storefront and exchange use will be essential to mass adoption.
bolster-testnet - optimizing the testnet should continue, however I question the need for more nodes and more miners; do these increase the ability to debug and test? as long as it exists and is functional then I question the need to increase resources here.
Disclaimer: Opinions below are my own and not necessarily in line with other OC members.
Might help when we are testing PIBD on testnet, but we are not there yet. We’ll probably announce the branch on keybase in case someone will want to test when it’s ready to be tested so at that point, it would help to have many people running this
Both are great. I do see a different value for a reference gui wallet for grin-wallet. But this is probably something that needs more debate than it really happened up to this point. A lot of it might depend on the system design choices and many other things.
I love this work. Small and maintainable codebase. It really depends on what we want to achieve. There may be value in having an explorer that explores the local node state. For instance, something simple like https://expedition.dev/ but where the data is gathered by querying the local node. I’m not sure if that’s useful, but it’s trustless exploring (though with much less features) rather than relying on trusting a specific service. But that’s clearly very up for debate.
PIBD and making sure the IBD works well for all nodes
safe-cancel and early-payment-proofs
unified transaction flow (setup → sign → sign)
an open source grin explorer
and then other options
regarding IPBD : will this really improve syncing time and also help going fwd with light node ? if yes, this is really important for UX
regarding unified transaction flow : will this improve usability ? i mean it’s still a 3 steps, i’am not sure about it
These are the advantages of having unified flow (imo):
people will know when the signing happens, so grin should be easier to understand for regular users (less “black-box” magic)
to know when to use safe-cancel you need to understand when the signing happens (since safe-cancel is basically “remove signature from the contract”), so safe-cancel without such scheme is way harder to understand (partially because of the scheme but mostly because of auto-receive)
it should be easier to implement support for multi-party transactions (eg. multiple payers)
manual confirmations should be easier to understand (and probably implement) which is important since contract rejection, split-fees and payjoins are (mostly) dependent on them
cleaner wallet api for people who want to create wallet gui
We’ll see about the sync times. It probably depends a lot on the available nodes with this support as well as some other things. I’m assuming you have in mind a pruning node when you say light node. PIBD has very little to do with pruning nodes, so it won’t help with this directly. It’s more about making initial sync more robust. It might help with speed too, especially if you’re stuck with some slow peer.
Having 2 steps would be cool, but we don’t know of a way to achieve this without introducing a lot of new assumptions. The unified flow is not a step towards having 2 step transaction building. It’s about making the bidirectional nature of these (payment/invoice) use the same commands. So it doesn’t “add” any new functionality, but it greatly simplifies the way we think about transaction building in 3 steps (imo). Someone creates the contract and both parties sign it. There’s also one more benefit to this which is code maintenance since it simplifies also the code paths though that’s my guess and was not confirmed by people that know a bit more on this topic.
I’d say that the biggest advantage is that it makes things more natural while it may also simplify the code - in general, having a single way of building a transaction is better. Ideally, contributing fees, payjoins, srs, rsr and possibly other options should go through the same building flow. The safe-cancel point is also a big one. You need to be able to inspect your contracts to see their signature state. I added some section on this in the (pseudo) implementation section of the document around fees and payjoins as well as the “view-contract” part. Let me know if this makes sense to you if you find some time to check it.
Contract itself would get a transaction related to it after it has been finalized (until then the contract is incomplete so there is no tx). This transaction would be like we know them today (number of confirmations etc). Maybe it makes even more sense to me to hide tx and have contract be our “tx”, so you have contract states (eg. confirmed etc), but that would mean that the wallet can list your contracts (some of them are waiting for signatures, some are signed but are waiting for confirmation, some are confirmed, some are canceled etc), which makes sense to me but i can see why someone would not want to go this way (people being used to transactions on blockchains etc).
There are a few other things, like ./grin-wallet sign --contract-id=<uuid> --receive=5 --use-input=<output_id> --fee-rate=0.00011 is missing an option for multiple inputs and outputs but that’s probably meant to be more precisely defined after we agree on such flow
PIBD and making sure the IBD works well for all nodes
safe-cancel and early-payment-proofs
unified transaction flow (setup → sign → sign)
more robust “exchange grade” wallet back-end
a GUI wallet that uses rust node APIs
an open source grin explorer (if the back-end is there, this should be a small bounty project)
IMO a GUI wallet front-end that is robust and and easy to maintain is very important long term, it is just that these other features are more important for safe use of grin. Also, as OC and or CC, we really should think about ways to decrease dominance of mining pools. I am just not sure, what it is we can do about it, but it does deserve some attention.
The name init may be misleading though, since in programming, that often initializes objects to some empty state.
Alternatives are setup, or drawup/draw (in real life, contracts are drawn up).
I hope writing RFCs is on the path, including for API changes.
I’m still waiting for a good argument as to why we should prioritize a GUI with the limited resources that leads to introducing changes without writing a RFC as they/we agreed before. But, anyways this an Open Source project.
It is not a fundamental change to protocol or anything, so no RFC is required in that sense. However, it should not only be a GUI, but minimal, a reference implementation, highly maintainable and making deployment easier. As such, the process should welcome feedback.
For me it is obvious that any good node implementation, needs a robust wallet GUI (like bitcoin core). For me such as GUI reference implementation is not of the highest priority though, hence I put it later in the list. It is something that might take some to do right.
Indeed, this is an open source project. What gets prioritized will depend not only on what we all think is important, but also what individuals feel like working on. I think that is fine. If however, people speak out their support for some of them, it does affect most likely how quickly they will be picked up by others because they feel the work will be appreciated, and requesting funding might also be easier.
I think that in programming init usually initializes an object to some starting state based on whatever is passed to init (which is what cli args are). I’ve never heard of contracts being drawn up (i always think of the word write instead of draw when it comes to contracts) so that’s less understandable to me. I understand the “setup” but that imo has the same problem as init (more understandable to computer guys) so maybe create/write could be an alternative (or draw if that’s what’s actually used in english).
Edit: I’ve googled it up, it’s actually draw and not write which is confusing to me since in my language write is used
I agree that init usually prepares an empty state. I’ve been thinking about this and we will have to introduce a new concept for transaction building with more than 2 parties. The way I’d consider breaking it down is by checking a 3 party computation. In this case we have initA -> setupA -> setupB -> setupC -> signC -> signB -> signA. However, the sequential actions by the same user can be grouped together to get (initA -> setupA) -> setupB -> (setupC -> signC) -> signB -> signA. This makes it so that if we only have two parties, we only have 3 actions to do if we batch them (which is what we do today).
It might makes sense to do batch by default and offer an opt-out like so
This means the setup happens by default unless you opt out of it through --no-setup.
Similarly, as seen above, the sign command can do a batch setup as well. Then we can opt-out of the setup with --no-setup. This makes the unbatched flow be
# Alice creates contract and does the setup action separately
./grin-wallet contract init -d grin1abca12dkc89d6j18 --receive=5 --no-setup
./grin-wallet contract setup --contract-id=1234123
# Bob does setup and sign separately
./grin-wallet contract setup --contract-id=1234123
# When Bob does signing, the sign command would recognize setup was done
./grin-wallet contract sign --send=5 --slate-input=slate1.gtx
# Alice signs
./grin-wallet contract sign --receive=5 --slate-input=slate2.gtx
I think this approach scales with more than 2 users because setup and sign are separate from contract initialization.
For most cases, I’d expect a batched variant to be used as it reduces the number of calls e.g.
# Alice initializes a new contract and does the setup in one step
./grin-wallet contract init -d grin1abca12dkc89d6j18 --receive=5
# Bob does the setup and sign in one step
./grin-wallet contract sign --send=5 --slate-input=slate1.gtx
# Alice signs
./grin-wallet contract sign --receive=5 --slate-input=slate1.gtx
I think it would be even more user friendly if we replaced init with new to get
Note: the last step would not require Alice to actually define the --receive=5 because the transaction context is remembered locally which means we have information on what kind of outcome we did the setup on. This allows for automatic validation that the contract did not change from the setup phase.
This decentralized block explorer was really cool to see; though from a distance it seems like managing plugins or updates would provide a point of centralization after all. With block explorers I am personally okay with a centralized resource for pulling data; ( I operate considering data collection is always on so why not package that and make available for the community- like so → Grin Blockchain Explorer
I agree, init may be a foreign concept to someone just trying to use a wallet. Maybe something more descriptive is helpful; like Start-Build or Start-Contract. I also like [Create]- marks the start of a build and is non technical.
