5 ms·

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 authent

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.

outside1234 5y ago
Thank you - super interesting
undefuser 5y ago
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?
- shiohime 5y ago
  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.

outside1234 5y ago

Thank you - super interesting

undefuser 5y ago

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?

shiohime 5y ago
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.