A Yeasty Update - March 2023

I’ve taken a personal action to get back into giving more regular forum updates on my Grin core development work. I’ve been quietly working away and relying on keybase conversations and github issues to communicate my activity to the world, but of course not everyone pays attention to those. I’m going to try being a tiny bit less quiet from now on in hopes that I can get more people to understand what’s coming down the pipe in Grin development.

As a bit of a catch-up, while I was away from Grin doing other things the number of active developers on the core team dwindled to somewhere around zero. After several months of this, I offered to come back to work on the project full-time in order to cover the gap. The arrangement was temporary at first, but then we agreed on a more long-term plan sometime mid last-year. Since I started work, I’ve undertaken a few relatively large pieces of development that I think will help move the project forward, and a have a list of a few more exciting (I think) things that I’m going to get to over the next year. I’ll spend the rest of the post talking a bit about these, as well as give a few thoughts and impressions.

I always enjoy working on Grin, but in all honesty being the only active developer across all of the core projects can be very challenging at time for a number of reasons. One of them is that I have a lot of code to look after, and movement can seem slow as a result. But I’m very much hoping the work I’m doing now helps brings Grin to ‘the next stage’, (whatever that entails), and that enough people start seeing the potential of Grin to allow us to attract and retain a fresh and healthy development team. I hope to be able 0to stick around as long as I can to try to see that happen.

So without too much further ado, here’s what’s happened over the last year or so, and what’s coming next:

PIBD

The term is used so much that I perodically have to remind myself what it actually stands for, but it means Parallel Independent Block Download, basically a fast-sync method that doesn’t rely on nodes having to maintain and pass around very kludgy-feeling zip files. The details are fairly complex and rely on a good understanding of the underlying data structures used in Grin, so I won’t get into too much detail here (there’s plenty in the RFC linked above).

I will say that starting with this was a good challenge that forced me into understanding areas of the code that I hadn’t been ‘mine’, so to speak. As many people know I spent most of my time on Grin’s initial development working on the wallet and wallet API, and some of the finer details of the node implementation were unfamiliar to me. Implementing PIBD helped rectify that somewhat, and it’s probably more important to have someone who understands the code than it is to have an PIBD implementation.

But happily we have both now, and PIBD is enabled on testnet only in v5.2.0-alpha.2, (which I now realise from the RFC we’re overdue to turn into a real release, going to address that soon). The deployment plan is currently linked in the RFC above.

Grin GUI

The last half of 2022 and into this year was mostly about getting the Core version of a GUI Wallet and Node off the ground. Although there is still a very long way to go, I’m happy to state that what’s there is mostly working at the moment. You can create or add wallets, sync up the node data and perform transactions via slate exchange on both test and mainnet. It’s not meant to be the fanciest thing ever, but it’s meant to provide basic functionality that presents a simple view on top of the entire Grin core stack while exercising our underlying node and wallet APIs.

A few things about the GUI so far:

  • The underlying GUI technology is one of the front-runners in upcoming Rust GUI Tech, Iced-RS. This route was chosen to avoid adding new languages to the stack, to provide maximum compatibility with the underlying libraries without needing any shims, and to keep overall project dependencies under control. The ‘surface area’ (i.e. the number of dependencies) of your more usual Javascript-based GUI techs is truly astounding, and I feel going native Rust is a good way to reduce the risk of your coins someday being stolen by some future change to a dependency-of-a-dependency-of-a-dependency.
  • The downside to this is that Iced-RS is under very active development and still very immature. There are a lot of the usual kinds of GUI widgets you’d expect to be in a GUI toolkit that just haven’t been developed for it yet. This means I’ve spent more time developing low-level GUI widgets (such as a table view), that I’d rather not have to do.
  • Developing anything in Iced-RS feels very, very manual and requires a lot of code, much of it feeling very redundant due to the way you’re kind of forced to structure your views and widgets. This being said, like most things Rust, once something is working it tends to work well and consistently, which is very much at odds with most GUI techs I’ve ever used, so that’s a plus.

There are no installers yet, and as I said there’s still a lot of work to be done, and we’ll hopefully be refining and honing it over time. If anyone really wants to get into core development, this is a very good place to start and one that I’d very much appreciate help with (hint-hint). Most importantly though, I think having this available gives us a place to perform experimentation on certain ideas without necessarily having to hard-embed them into the underlying APIs (more on that in a bit).

In case you’ve missed it, development of the gui tends to be discussed on the GUI Keybase Channel - grincoin.teams.gui_dev.general.

Other Bits and Pieces

Plenty of other work ongoing maintenance and bug-fix work has gone on a bit too numerous to list here. More nodes have been started, a few tools have been created, I’m more familiar with areas of the code that hadn’t been ‘my area’ so to speak, and I’m just generally around in case of any issues or emergencies.

Current Work and Future Plans

With PIBD deployment in its extended roll-out phase and the GUI well underway, I’m starting to focus on a test implementation of some of the more exciting ideas that have been knocking about and I think are now crying out for some implementation attention. At present these are:

  • Simple Contracts, which has already been mostly implemented by Phyro. I’m currently reviewing and looking into implementation details that may be remaining. You can read all about this here, but I think it has great potential to simplify transactions from both development and user perspectives. To facilitate this I’ll also be implementing:
  • Early Payment Proofs, with the intention of introducing them alongside simple contracts. Some slate update work is required which I’m currently in the middle of doing.

The idea is to get both of these up and running in an experimental branch of the wallet and then integrate them into the new GUI to see how well everything all works together in practice.

There’s also a lot of discussion going on around nostr, which on first glance seems like it may be a good way to facilitate slate exchanges. There is definitely some promise here, and I know other grin wallet creators have already been experimenting with it. It’s exciting, but the tech is still relatively new and in flux. It’s also very prone to spam which to this point tends to be mitigated via one-off BTC payments to relays. There feels like there should be a way to include a relay payment as part of a Grin transaction, but there’s no obvious way to do this without a hit to privacy.

In any case, I will definitely be experimenting with integrating Nostr into grin-gui alongside the other transaction work above, and I hope these will all combine to bring Grin to the next level of user-friendliness (which is admittedly not a high bar at present).

Future Updates

So that’s about all that’s going on in OC land at present, and I’m just ticking away and happy to focus mostly on development. As I said earlier, I really hope we can get enough momentum going with the project overall to start to attract some new talent, and I think a lot of the upcoming work across new features and the GUI will help that. I’ll post updates at more regular intervals going forward (though perhaps not quite as long as this one.

One quick thing I wanted to say is that if you’re working on a particular Grin-related project and having issues with our APIs, the best thing to do is let me know in keybase and you’ll probably get immediate attention. We need to clean up the backlog of issues on github, but it can sometimes be hard to know if an issue is badly affecting someone just from the issue itself.

Lastly, I know Grin is going through a period of, say, ‘lesser excitement’, but this is normal for any long-term project that’s worth doing. Initial excitement is always followed by a long period of plugging away where pure and boring discipline needs to take over the role that excitement once fulfilled. BUT, I firmly believe Grin is a project that’s worth pushing over that hump.

I always tell people that the entire cryptocurrency space is about 99.9% pure bullshit and about 0.1% actual innovation. Grin, for all of its faults, firmly belongs in that 0.1%. It’s an honest effort that tries to focus on doing one task very well, and does it differently to how others do it. It belongs to everyone, and there’s no room full of impatient investors forcing the development team to bolt all sorts of buzzwords onto it. Progress is slow, steady and thoughtful, and Grin is going to endure through this crypto winter, the next one, and the next one. I look foward to helping it evolve.

39 Likes

Amazing! Long live Grin!

1 Like

What would the privacy issue be there exactly?

This update rocks!

Nice update, and plenty to be excited about IMO :rocket: !
The early payment proof are transaction flow independent, therefore I assume they will be implemented for all transaction flows? Nothing wrong with current payment proofs for SRS, but I like the idea of having a universal payment proof system for all transaction types, as well as a universal transaction contract flow :sunglasses:

Well done, but does it mean you keep working alone? I saw a lot commits only from you. IMO we can use funding budget more effectively by hiring more people with hourly rate. Project should have development Kanban board to understand what was done and what will be done. Community also needs to know for what money were spent, every working hour should be explained. I think Grin should follow idealogy of fairness and transparency. I don’t understand what is “OC hiring” and can not find any info at resources.
P.S. I can not find gui_dev channel at Grincoin keybase team to join, it is private?

Yes, that’s why we want to get early payment proofs ready, because they work very well with universal flow and aren’t tied to the order in which things happen.

1 Like

Nostr type 4 messages (i.e. DMs) are supposed to be end-to-end encrypted, so you can’t include another party (like a relay operator) in them without telling them all about the transaction and breaking the end-to-end encryption. Also, no matter what you do (going to cut and paste from phyro’s keybase chat yesterday ‘the messages are private, but the metadata around it isn’t e.g. IP, timing, queries, events you send can all be linked and analyzed’

Those are just a couple of concerns from a cursory exploration, but like anything a lot of thought and consideration and understanding of tradeoffs is required here. Some privacy tradeoffs might be acceptable to most users most of the time, but we need to make sure they’re well understood.

2 Likes

I don’t think that’s a good idea since it creates pressure to code things faster which means more bugs and we all know how important it is to not have bugs in a blockchain related software

2 Likes

This type will likely be retired or fixed soon because it’s just not good. The community wants better ways to DM. But regardless, yes you will likely be showing who you are talking to but you can still have the contents of your message be private.

For example, no one needs to know that a slatepack is in the content of the note :slight_smile:

No. That would be unproductive, there is no need, Grin is neither an outsourcing company nor a talent pool. That would just create distraction by people trying to opine on the value/price of the developer. No one is “hiring” nobody, the OC isn’t a formal institution. The updates (for the regular user) and the github repos (for more advanced users) is just fine.

I don’t know how the OC is operating and could care less, but whatever they are doing is working, and if it works don’t touch it.

Kudos to @Yeastplume and thank you for your effort and time :clap: :clap: :clap:

8 Likes