Thanks. That could be used as a temporary solution to get things started. It would work as long as it’s not abused and the network’s utilization is small.
But we may have to think about this problem a bit more, because in the long run without the user being able to generate PoW they cannot onboard onto the network.
The problem these services have is that the user cannot pay for the services because they can’t interact with the network if they can’t generate PoW. They can’t receive their funds from the bridge nor can they fuse plasma for their account if they can’t generate PoW.
Maybe the services could be paid for with other cryptocurrencies/fiat but I think that might create a confusing UX and of course introduce trust issues.
Wonder if there another CPU algo that can be run in the browser?
From link above regarding RandomX:
Web mining is infeasible due to the large memory requirement and the lack of directed rounding support for floating point operations in both Javascript and WebAssembly.
Maybe this is a good point to bring up in the Dynamic Plasma discussion. Before RandomX is implemented, we could explore the option of leaving an “incorporation lane” to the highway that can be exclusively used by “new” accounts running a browser wallet. This is just another random idea, but hopefully gets the brains working
Based on some research I did the options are pretty limited. One alternative “ASIC resistant” algorithm is Dero’s novel AstroBWT algorithm that is claimed to be FPGA, ASIC, and GPU resistant but it would need more research to determine if it’s otherwise suitable for us.
But even if we had a browser friendly PoW algorithm, I’m not sure if it’s a long term scalable solution to generate PoW in browser environments (or on mobile phones for that matter), because once the network usage picks up, the PoW difficulty will rise and generating PoW in a browser will be slow. People hate slow.
One idea of how these PoW/Plasma services could work is to get pillars to operate a kind of “wallet provider” service, in exchange for the user’s delegation. The wallet’s UX would have to be tightly coupled with the “wallet provider” service. The wallet provider would be responsible for generating PoW/fusing Plasma for the user, and these concepts could then even be abstracted away from the user. Ideally the wallet provider will have the resources to provide fast transactions to the user. If the user is not satisfied with the provider, they can always change it by delegating to another pillar that offers the service.
When onboarding a new user the wallet provider could check that the user actually has a pending transaction in the bridge and it will only generate PoW for that transaction. The wallet’s onboarding flow could be made in such a way that after the user has selected the wallet provider that onboarded the user, the user will have to delegate to that pillar. Referral links would ideally be integrated also, so that pillars could advertise themselves as wallet providers and the wallet would onboard the user directly as a delegator to that pillar.
It’s hard to make such a service unabusable but wallet providers could limit how many transactions the delegator can send within a time period and if the user is not a delegator they might only generate PoW for a transaction that is a delegation transaction to the pillar.
This is interesting. I assume the wallet “service” offered by Pillars could be run on specialized hardware, especially since this will be CPU intensive. Pillars will potntially need to run CPU farms.
I suspect that a decent VPS would be enough at the start, especially if it’s combined with fusing some plasma to the delegator but yes, with sufficient network utilization the providers would need specialized hardware. Maybe there could be a separate market for PoW generation where pillar operators can make deals with PoW providers. Lot’s of people have Monero mining rigs that aren’t all that profitable at mining Monero for example.
From the user’s perspective the goal is that they get free, fast, and effortless transactions and I think if we’re looking to maximize user friendliness and achieve “global adoption”, the key is to abstract away as much as possible. The user doesn’t need to now what PoW is, or what Plasma is to use the network. They don’t need to select what pillar to delegate to from 100 options, since the wallet can onboard them as a delegator to a specific pillar and advertise the fact that they get free transactions and x% APR for their funds while doing so.
In the future we’ll probably have DeFi services, NFT marketplaces, etc. built on sidechains and L2 solutions and we’ll want to abstract away the boundary between these different layers.
The same goes for BTC and zBTC and ideally the user can send native Bitcoin to a Zenon address for example. The wallet will automatically bridge the BTC to zBTC, and the recipient will receive zBTC, but the complexity is abstracted away from the users. From their perspective they’re sending native BTC to a Zenon address.
We need a browser wallet. I suspect developing a snap is faster and will be more secure than building a wallet from the ground up or rebuilding what Dexter prepared.
Metamask has wide adoption. I believe people will feel more comfortable interacting with NoM over Metamask + a snap.
I like the idea of abstracting away the PoW / Plasma fusing to Pillars. Initial the PoW required by Pillars will be low, and as it grows so will that market place. it will evolve. You can count on me to provide a PoW service to my delegators.
Question: will we offer “Advanced” user the ability to run RandomX on their local PC to make their own PoW if they are technically capable?
Ideally we want to offer the option to use the wallet without a wallet provider. Meaning you can run your own node and do pow generation.
But if the user is someone who absolutely does not want to connect to any third party services, I’m not sure how well we can cater to that user group in the long run. Once we have the extension chain, the wallet will need a connection to an EVM node. If we integrate a Bitcoin wallet into the snap, it will need a Bitcoin node. Maybe we want to add support for ordinals and BRC20 tokens, then it will need a connection to Unisat’s API for example.
I think it’s possible that the user can provide their own infra for the wallet but eventually it will get more complicated. Most extension wallets/mobile wallets rely on a centralized backend, so having multiple pillars provide the backend separately is still an improvement to that, with a negligible effect on ease of use.
There’s a reason why the most used LN wallets are custodial, a better UX ends up winning over the users. Most people don’t have their BTC life savings in them, so I think that’s a reasonable compromise people are willing to take for convenience.
I like the wallet provider idea, and we don’t seem to be compromising much at a glance.
Regarding the more knowledgeable/hardcore user group, I think we are already offering best-in-class UX in syrius, while being cross-platform, and we should just maintain the standard moving forward as we increase the capabilities of the wallet/network. I don’t see a good reason to “stay” in the browser for such an user unless a mobile device is being used.
I agree, but I want to highlight that even with the wallet providers the snap wallet would be non-custodial and only the user can access the keys. The keys never leave the metamask extension.
Syrius is definitely best-in-class when it comes to “core” network wallets. It has its role as our core wallet, catering to power users. I think syrius should continue to focus on stability, security and minimizing its dependency on external services and new features should be added when necessary. On the other hand a browser based wallet could focus more on experimentation, ease of use and cater to a different set of user needs.
I would have to make a proper description of the architecture, of the different components, and of the potential risks, so that the community could better evaluate and discuss the idea.
But before that, how high of a priority would this kind of a project be? Community members have voiced their opinion that developer resources should be focused on critical tasks only. I understand that protocol upgrades are top priority right now, but I don’t consider myself a protocol developer, so network upgrades aren’t really in my comfort zone.
Another area I’ve researched is how Bitcoin P2P swaps could be implemented in syrius, and while the community is expecting that feature, I’m not sure which of these projects (snaps wallet or BTC P2P swaps) would drive more adoption to our network in the short term. I can’t really focus on both projects at the same time.
I’ve also volunteered to develop the syrius UI for the governance module that @georgezgeorgez has been working on, but I don’t expect that to be too big of a task.
If we can get the extension chain that @aliencoder is working on into use in the coming months, then I think the snap wallet would make onboarding users onto the extension chain much easier, driving new users into our ecosystem. The possibility of adding Bitcoin integrations into the snap is also intriguing, although it would take some time to get there. Ultimately I believe that sooner or later we will need to start tapping into the vast user base that exclusively uses simple-to-use extension and mobile wallets.
Then again Bitcoin P2P swaps in syrius would be good PR for us, allow for more cross-chain liquidity, and could get more Bitcoin people interested in our network.
We plan to hold the dev meeting tomorrow (Friday @ 12 PM UTC) and hopefully we can dive into this discussion in more detail then.
In the meantime, I think the fastest path to onboard more users and increase adoption is a simple, secure, and reliable web wallet. Metamask is best in class and leveraging their platform will help our users feel safe.
I also think native P2P swaps with BTC is an important use case. However, the number of people that will use such a feature will be much less than people wanting to use a web wallet. Also, once the EVM side chain is up, and the web wallet is bringing in new people, it’s possible (likely) some BTC devs will get interested in what we are doing. Maybe these new devs can help architect and implement native P2P swaps with BTC. Or at a minimum, they can join forces with @vilkris@sol@CryptoFish and @aliencoder to work on the feature.
In summary, I think implementing a NoM snap for Metamask is an A+ priority for stimulating adoption, especially once the side chain is available.
