Developing a new browser extension is now obsolete since Metamask released snaps.
Let’s discuss about integrating Zenon into Metamask directly.
5 Likes
Interesting. I’ll definitely investigate this. Thanks for sharing.
3 Likes
What’s the best part?
- No more dev work on our own browser extension
- Access instantly >10M Metamask users
- More focus on Syrius desktop & mobile
4 Likes
Let’s also address the elephant in the room: users can now easily swap anything to BTC and I doubt the average user even know or even care (unfortunately) about the difference between P2P swaps native BTC to USDT or anything and this solution where they can keep using Metamask.
This can be an issue heavily undermining the narrative we’re trying to play with BTC.
1 Like
Some people come with solutions, others with problems.
This was about bringing Zenon closer to ordinary users.
There are multiple narratives in Zenon, go with the one that suits your vision/goals/expectations.
2 Likes
Both aren’t exclusive and I’m not attacking your proposal nor your work. So get down of your high horse. There aren’t 1000 narratives and this need to be at least discussed. Maybe not in this thread though.
The question would be : is this change other aspect of ZNN development or make those irrelevant? If yes how and if no why. The field is evolving and this tends to reformulate problems and how to fill gaps.
I think MM Snaps are worth considering, though we may not have many devs that can/will work on this.
Any volunteers?
2 Likes
Maybe Dexter has bandwidth?
1 Like
I’d need to research what possibilities Snaps could offer us but I might consider working on this. I’m interested in how this could improve the ETH bridge experience (and maybe the extension chain experience?) to make the onboarding into Zenon smoother.
I’m finishing up the ZTS<>ZTS P2P swaps project so I should have more bandwidth soon.
BTC<>ZTS P2P swaps are another possibility, so depends on what makes more sense for us now.
6 Likes
I see another benefit of Metamask Snaps:
Users will be able to easily swap ZNN to XZNN directly inside Metamask.
We will need to replicate this flow inside Syrius desktop and mobile as well.
2 Likes
After a quick dive into these snaps they seem pretty cool.
The snaps are completely open and permissionless, meaning that we don’t need to worry about having to publish anything to an “app store”. We just publish an npm package.
I suspect there will be a ton of development & hype happening around snaps in the near future since the barrier for devs to start building is very low, and you don’t have to worry about lots of the annoying complexities of building a complex extension because MetaMask handles that for you.
And like Aliencoder said, you get access to the MetaMask userbase of millions of people so you don’t need to onboard them into your own extension.
EVM <> Zenon dapps like the bridge can build a full experience for the user, only requiring MetaMask to be installed. Nothing stopping us from adding Bitcoin functionality into the snap as well.
For the purpose of allowing low effort, maximally easy onboarding into our network, I think this is a good option for that.
Some technical aspects and ideas to consider:
-
I think being able to send PoW transactions with the snap is crucial for an easy onboarding experience. The need for gas in EVM networks is such a UX painpoint.
Apparently WASM can be used with snaps, but there seem to be limitations to how long a background process can be executed for on the snap: https://docs.metamask.io/snaps/concepts/lifecycle/
60 seconds may not be enough to send a PoW TX but we’ll need to investigate this some more. -
It would be nice to allow the user to use a local node with the snap. The snap could work as a proxy between a webapp and a local node. We would have to define an RPC interface that webapps could use to make RPC calls to the node through the snap.
-
Cron jobs could possibly be used to automate the receiving of TXs in the background (among other stuff): https://docs.metamask.io/snaps/reference/exports/#oncronjob
-
The snap could be used as just a simple keystore & node provider for dapps. UIs for basic NoM functionality (like staking, delegating, etc.) and the EVM bridge could be provided by webapps (that anyone can build) and the snap would just be used to sign & send transactions and provide a node connection. Of course all this functionality could be built directly into the snap as well.
I’m impressed at what MetaMask is doing here.
Yes exactly. Could probably make a smooth experience between ETH <> ZNN <> XZNN.
10 Likes
Whereas Bitcoin is the lesser volatile and less moonboi-ish asset, I think people who buy BTC are generally more aware of what they are buying.
I still think that decentralization will be the core theme of the next bull run, and the task of educating the market will not rest solely on our shoulders. The market will be looking for a solution like Zenon.
SEC and FEDNOW may turn out to be some of our best advertising.
We don’t chase, we attract.
1 Like
1 Like
For the moment it’s enough, but I’m not sure when dynamic Plasma gets integrated.
This way we can offload the PoW creation to the node.
1 Like
I spent some more time testing and researching the snaps platform and made the following findings:
-
Keystore generation works - a zenon keystore can be derived from the metamask account. This means that the zenon keystore is tied to your metamask account. It should not be possible for anyone to link your EVM accounts to the zenon account.
-
The snap can indeed be used as a relay between a webapp and a local node, meaning that dapps can be used with a local node.
PoW generation:
-
The 60 second timeout is still a problem. There is currently a feature in the snap environment that allows for long running processes to be executed, but unfortunately this feature is deprecated and will be removed soon. On the bright side the snaps team is actively working on providing a new solution for long running tasks: Long running Snaps for synchronous work · Issue #1604 · MetaMask/snaps · GitHub
-
Using the current C++ implementation for PoW generation via WASM isn’t really feasible in a snap. The snap runs in a secure execution environment that has limitations that complicate the usage of WASM in a snap. There have also been reports of issues with WASM performance: Investigate wasm performance · Issue #1422 · MetaMask/snaps · GitHub
-
I overcame the WASM issues by rewriting the PoW algorithm to work with Typescript directly which allows it to be run inside the snap.
PoW generation feasibility with dynamic plasma and RandomX
A new problem that came up in regards to PoW generation within browser environments is that if we change the PoW algorithm to RandomX, like has been suggested, then browser-only onboarding into our network will not be possible. It is not viable to compute RandomX in browser environments: RandomX/README.md at master · tevador/RandomX · GitHub
This means that browser based wallets, like the snap wallet, will have to rely on either a separate locally run program that can do the PoW generation, or on external services that provide PoW or Plasma as a service. Currently the only way to onboard onto our network without external services is by doing PoW transactions.
If the snap wallet requires the user to install a separate program on their computer to be able to use the wallet, it interferes with the idea of using browser wallets to allow for a very low effort onboarding experience. Getting the user to install and trust the program is a UX challenge.
Another option is to build external PoW and Plasma services that can be used by wallets, but how are such services incentivized?
High level view of a snap wallet and the related components
4 Likes
We need a good web wallet IMO that is easy to use and install with no “special” steps. I guess the desire to move to RandomX is to prevent an ASIC style attack on the account blocks?
We need ease of use but want to prevent spam attacks. Incentivized PoW seems like another step that we are too young (small) for. Curious what others think.
If it helps initially until a more viable solution can be found I could setup an API route for the plasma bot which the snap could use?
We can adjust the parameters of how much and for how long QSR is fused for this specific application. The bot has 70k QSR available and only a tiny fraction is ever in use at the moment
3 Likes
Maybe there is a market to process PoW. Users could either fuse QSR or pay a 3rd party for PoW (right in the app).
I might be interesting in offering a PoW service. I have a location where I use to mine. I have a utility contract in place for $0.05/kwh.
1 Like