Hacker News Reader

Agree. Gets lost in the decentralization memes? Strong, shared identity and auth for digital assets can't be overstated? This enables new models for digital ownership, value, trade, markets and storage of information.

I've been brainstorming a lot honestly about the implications that simple proof of identity and proof of ownership can really imply. I honestly might try my hand at creating a full out replacement for existing authorization techniques sometime next year, I've got some ideas and frankly if it works it's so simple it's stupid lol.

It's so fascinating to me to realize that users being owners of their own private keys allows for us to create websites that don't rely on traditional registration flows, SSO, email addresses, password handling, or anything. It almost feels like cheating compared to the pain I've had to deal with in the corporate world implementing services like IdentityServer4 or Keycloak.

Yup - love how easy it is to login to web3 projects!

Have you also looked into Zero Knowledge?

It lets someone prove that they know or have something without giving up any information about what they know or have.

Not Boring did a good piece on it. https://www.notboring.co/p/zero-knowledge

tldr: you can enjoy ZKPs without blockchain

---

Adding to OP's comment a bit of context:

As someone deep into ZKPs related to blockchain I should note that ZKPs have nothing to do with blockchain in their origin; the cryptography behind them was developed in the 80s (even protocols like zkSNARKs). Many applications are also not specific to blockchain and a lot of work on their mathematics does not relate directly to blockchain either

That said, a decent chunk is now directly for applications in that field. For instance, key decisions around the cryptography used by Circom (a zkSNARK language) are predicated on the idea they will be used in EVM smart contracts. Same is true of snarkjs that exports Solidity verifiers.

I have not actually, I'll look into this, thank you for sharing!

Totally agree, built a few dapps this year and the auth story is always such a breeze.

Had to work on an old project for a client that was using oauth2 and it felt so archaic.

Is there a reference you could share for how you did authentication / authorization?

I unfortunately don't have an easily available reference really, it's all stuff I architected really myself. I can give a quick rundown though.

For the authentication side:

authentication, is simply connecting your wallet. Since each user has to have a wallet to interact with blockchain tech, that just simply means each user is the owner of their own private key. You can utilize this fact by connecting user's wallets. Once a user connects their wallet, you have proof of identity. If you need to verify it further, you can also have them sign a message and validate the signature on your backend.

I've been working with Solana, and some of the wallet providers I've been integrating with (specifically Phantom wallet) have very easy to use APIs that allow for requests to sign a message. It uses Ed25519 for signing, so it is an incredibly quick operation to verify that the signed message is a legitimate message signed by the wallet they claim to be. You can even add something like a timestamp or whatever to the message, to avoid static message signatures phished from other sites.

Once you have verified their identity by connecting their wallet, you can simply use these facts to retrieve whatever data they require.

On the authorization side:

I can really only use the example for my NFT project for authorization, but there are certainly many other ways to implement authorization. I have a service that I've created that I wanted to lock down to only be accessible to owners of a specific NFT. Since NFTs are essentially a proof of ownership concept natively, to provide access to my service I decided to implement the following:

1. Authenticate the user via connecting their wallet

2. Using the same signature method I mentioned above, sign a message, and verify the signature.

3. Once I have verified the user is who they claim to be, I check the token balance for the NFT that exists in their token account. Since NFTs are single issue, all I need to do is verify the user is holding the token they are attempting to use for accessing this service.

For example, if a user X is attempting to access the service for token Y, it's as simple as:

1. Verify the user is who they say they are

2. Verify the user holds the token they claim to be holding.

This is how I've been implementing authentication and authorization on my project. I think it's been really fun to architect this solution, we haven't gone live yet but I think that it'll work how I am expecting.

Thank you - super interesting

Thanks for the information, that is very useful. Do you have a list of “gotchas” to watch out for while working with Solana, or blockchains in general?

I only have experience in Ethereum, in terms of writing smart contracts. For Solana, I've yet to create an onchain program but understand some of the key differences between the ecosystems (please note, I am by no means an expert. I've only had exposure to the ecosystem for around 5 months as a developer):

Solana works completely, and entirely different than ethereum. Like almost nothing works the same lol. In Solana, on-chain programs cannot store tokens in the same way that smart contracts can in Ethereum. Instead, you create essentially temporary wallets (these are wallets with public keys that fall outside of the Ed25519 curve), which act as temporary storage for whatever transaction you are performing. This is an important difference that is very unintuitive when coming from Ethereum.

Likewise, Solana has a solution for limiting amounts of computation in a single transaction. Having an upper bound on the amount of computational complexity that can occur in a single transaction I believe is a really smart limit to have, as it forces developers to be very aware of the computational complexity of their code. Ethereum of course is the same in the sense that it strongly encourages optimized code, however, poorly optimized code punishes the end user by charging higher gas fees. With the cap on Solana, if you attempt to execute a transaction that is beyond this threshold, it fails the transaction and returns any assets to the respective parties. Of course, if you are doing something that exceeds this threshold computationally, then you can make multiple transactions (check the Solana wormhole bridge for a very valid example of this.)

Ethereum is also a more mature development ecosystem at the moment. There are tons of different tooling and projects available that really allow you to build applications in a truly innovative fashion. My personal favorite project on Ethereum is The Graph - which allows for you to index any data/events that are executed on a smart contract, and then access that indexed data via GraphQL APIs. It's incredibly powerful, and with some creativity will allow for you to write decentralized applications using this as your decentralized database. It's quite a fascinating project.

However, I cannot recommend currently developing on Ethereum directly. It is experiencing terrible scalability issues (I am aware that they are working on different techniques and proposals to address this, however right now to use Ethereum directly is financially impractical). Simple transactions as of today often will cost $100 or more, and take ~30seconds to a minute to transact. Solana on the other hand is designed in a way that transaction costs should never exceed 1 cent (IIRC). They currently cost a fraction of a cent, and execute in seconds.

There are of course different layers that you can work with in the Ethereum ecosystem, and if you are interested in working in the space, I strongly recommend checking out other Layer 2 EVM solutions. There are a lot of different layer 2 chains that let you leverage Solidity and most of the Ethereum tooling while avoiding the absolutely insane transaction costs.

At the end of the day though, if you are interested in a project in the space, I recommend checking out the different chains strengths and weaknesses, play around with a few different ideas, maybe enter some hackathons to get some hands on experience. Each chain has their strengths and weaknesses. For my current project I chose Solana because I believe it has the best scalability solution for all programmable chains today, and I can release a unique project on there, charge a low price for minting our tokens, and not worry about users being unable to afford the mint due to transaction costs. If I wanted to create a more complex dapp, I'd likely use an EVM chain, so I can leverage The Graph and truly decentralize every aspect of my app.

I really appreciate you sharing you perspective on this (as someone getting started with developing for EVM myself)

If you don't mind answering two more questions:

- Why did you choose Solana instead of Polygon/Avalanche/Fantom/Harmony or any of the other EVM compatible chains? I realize you mentioned Eth's scalability issues as a barrier, but I believe Fantom, Polygon, Harmony are roughly the same as Solana in speed/cost. (Fantom is more expensive than harmony, but a bit faster. Harmony transactions cost pennies but take 3-4 seconds to resolve, and Polygon is usually a fraction of a penny, but seems to take 4-6 seconds for finality)

- Can smart contracts written in Solidity really be ported over to Solana using some tool I've heard mention of? Or is that really just more of a quickstart helper? From what you described it sounds like a lot of the contract logic would have to change

No problem, I've been doing basically solo research and experimentation for the past few months so it's fun to at least share a bit of knowledge I've accrued along the way.

For as to why Solana - it's a combination of me being very impressed by their tech as a user, engineering curiousity, and market research as to why I decided to use it for my project. I think that despite Solana having exponential growth this year, that it's likely we are still early in that specific ecosystem. I have no doubt that they are in it for the long run, and there are already some pretty impressive projects in the ecosystem and a lot more upcoming.

This is my first real independent venture since leaving the corporate world, so my personal belief from evaluating the ecosystems is that I'll put my bets on Solana. I want to both charge a low mint cost, and if I'm successful in building a small community and raising enough capitol to prevent me from having to go back and get a traditional job next year, support a longer term gaming project, and a lot of upcoming gaming projects seem to be converging on the chain. So, it's pretty much that. I don't have the same faith that these ETH L2 solutions will be heavily used 5 years from now that I do with Solana, and honestly the NFT market has been exploding lately there. Nothing's certain of course in this space, so I had to put my chips in some bag.

I also had some very poor experiences in both ETH, as well as Polygon, and wanted to just try something different. Polygon is very cheap and works well when it works, however it seems to be suffering from congestion issues on the validator nodes. I had a transaction stuck in essentially a traffic jam unable to do anything other than wait a half hour for it to clear, and did a little bit of investigation in social channels and saw I wasn't the only one that was having periodic issues with the chain. For other chains, I have only had positive experiences with AVAX, so there is that.

And yeah, there is the ability to use Solidity contracts to Solana apparently. I've never used this tool, but heard about it the other week and seems like it will be a pretty cool project to follow - https://neon-labs.org/ - They seem to be an EVM for Solana, they were I believe unveiled at the recent Solana conference. I've not looked into them more beyond this, but yeah they might be a good project to look into if you are interested in porting some Solidity contracts to Solana.

You can check https://collab.land/ which allows Discord users to access certain channels after proving token ownership.

For front end auth it’s as easy as pulling in a react web3 lib.

Authorizing the service itself to act on the users behalf is a little trickier and usually involves contract signing.

Maybe a curated marketplace would be a good place for those projects?

Yeah, there are some marketplaces that are trying to only curate high quality projects, and others that are more open to accepting any project. It's actually pretty crazy right now, there's so many ongoing independent projects that some of these exchanges and launchpads have huge queues.

I'm hoping that my project will be able to be featured on one of these marketplaces, but it's been rough out there. I think once I finish up and polish our roadmap and goals for the project, in addition to the already existing website and short video preview, we'll be able to get in on one of those. Fingers crossed, at least :)

What engine did you use?

Godot