Given the nature of the Treasury DAO’s large payment to Brave for the addition of Polkadot support in Brave Wallet it was requested that we provide updates on the current state of things. So, I’ve decided to start a thread to give you all an update on where things are at and provide an ongoing line of communication between our team and the community. We understand there were decisions made on whether to spend towards our project or others, so this is a good way for us to keep you all up to date on where we’re at. This is the first time we’ve done an integration between a DAO and Brave, so please bear with us as we’re learning how to communicate updates on this in this new way for us.
For reference, I’m a security engineer at Brave with about 8 years in Web3 (5 previously working on Decentralized Identifiers and Verifiable Credentials and now 3 with Brave) and quite a bit of my time has been spent in open source communities. So, I understand how just being open and transparent with communications is an important part of the success here.
My plan is to keep updates in this thread and also to keep an eye on questions that come to us from here and try to respond as promptly as possible. Please feel free to drop me questions as they come and I’ll respond as best I can or follow up with the team internally and get answers.
As a first update, here’s where we’re currently at:
we’re reviewing the addition of the new sr25519 rust crate dependency. One of the key architectural decisions we’re currently evaluating internally is whether we think this is a viable candidate to move into a WASM module ran within a separate WebUI renderer process. The alternative (which is what’s implemented) is to keep it as native process code and incur higher maintenance costs from it for now, and then refactor it to a WASM module later.
For a bit of background context on this, we’ve found with our previous work integrating rust dependencies that this can be quite the maintenance cost incurred because Chromium doesn’t rely directly on the Cargo toolchain and Crates. We have to manually keep these things in sync. What this practically means is that if security updates are pushed out to dependencies or even general dependency bumps then it can take multiple days to get the updates added, reviewed and merged. That process is both expensive and can lead to direct user impact if a vulnerability is serious. When isolated to a single blockchain project it’s not normally a problem, but when you have to start maintaining these dependencies for multiple chromium components and multiple chains for the Brave Wallet component alone the cost adds up quite quickly. Especially when we’re constantly rebasing Chromium too which can sometimes impact these third party dependencies if we need patches or other integration layers.
So, the current tradeoff we’re assessing is whether now is a good time to start relying upon a WASM module in a WebUI renderer process rather than natively integrating the code and consuming it within the browser process. The advantage here is that we reduce the maintenance costs, but the tradeoff is that we may incur a slightly slower signing operation (should be neglible for Sr25519 IMO, but for things like ZKP signing operations it’s much harder which impacts other chains) for this and WebUI support for iOS only just recently landed in like the past month. We’ve been working towards getting this for nearly a year now. This is what made it feasible to consider this as the first implementation of it. So, we’re gathering information from other components that are already making the transition here to help us be informed on the best architectural decision here on how we want to implement the keyring implementation for Sr25519 support.
We’ve spent time on product design and changes needed for legacy Polkadot integration. One of our principles we have with our wallet is that we want to maintain a cohesive design across each chain and so we’ve started making sure that’s possible with Polkadot. For example, we currently support Buy, Bridge, Swap, Send with every chain from a user perspective. However, due to the way we split code between the Brave Wallet UI front end renderer process code and the browser process code, it impacts how we design our inter process communication channels. Similarly, if we decide that Sr25519 should operate within a WASM WebUI renderer process, we’d need to define the properly IPC channels to align with this to make sure the UX can be cohesive. On that front, we’ve started mock designs of what this might look like and here are some images of the first draft. It is still subject to change though and we’re also looking at how the recent changes to unified addresses align with our current UX to be able to support this.
Hopefully that provides some context as to where we’re at with things! Thanks and feel free to drop any questions you’ve got here in this thread.
Have you considered using scure-sr25519? It’s fully audited and built on top of other fully audited components… Although, I suppose that you rather avoid JS and use a “native” implementation?
Correct, utilizing a JS implementation isn’t really possible for us. It would introduce potential chromium layer violations around which processes are meant to be handling and parsing the data structures for performing browser operations. In general, JS code is reserved exclusively for front end code and for pages to use it within a renderer process. It’s also normally sandboxed to align with the security model of each process type (e.g. WebUI is considered a specialized renderer process that has some slightly additional permissions, and untrusted WebUI is basically just a normal renderer process with a brave:// origin). Nearly all business logic is implemented as C++ code within chromium. Even the idea of moving part of this business logic to a separate WASM module isn’t really standard practice within the chromium code base, but it’s something we’ve found works well with other components hence why we’re trying to expand it’s pattern to the wallet.
Yeah, that’s what I thought… Thanks a lot for the elaborate explanation!
It’s just that when I saw that you mentioned that you were considering the option of running it into a a WASM module within a separate WebUI renderer process, then I thought that perhaps -since you were already opening that can of worms- this could have been an option… But yeah, I totally get your point, thanks again for the explanation!
We certainly can consider it if we can go down that path. I suspect it might be slower, but in any case it’s good to know of this alternative. Thanks for sharing!
