Web3Auth exists to make digital ownership and identity human-centric and accessible to everyone

Web3Auth

What's Inside Play to Earn

ইনসাইড কি আছে উপার্জন করতে খেলুন

Was ist drin? Spielen Sie, um zu verdienen

¿Qué hay dentro de Play para ganar?

Qu'y a-t-il à l'intérieur du jeu pour gagner

अंदर क्या है खेलो और कमाओ

プレイして稼ぐ内容

무엇이 들어있나요? 플레이해서 수익을 얻으세요

O que há dentro Jogue para ganhar

На чем можно заработать в Inside Play

Kazanmak İçin Oynamanın İçinde Neler Var?

Có gì bên trong Chơi để kiếm tiền

玩赚游戏有什么用

In an era where digital security is paramount, Shamir's Secret Sharing (SSS) stands as a revolutionary technique, offering robust protection for sensitive data. This cryptographic method, developed by , is not just a tool but a safeguard, ensuring that a secret is not just hidden but also shared securely. Adi Shamir In this article, we delve into the ingenious mechanics of SSS, exploring its foundations in polynomial mathematics and its practical applications in securing data, from corporate secrets to personal credentials. In our case, we will save credentials for the user account, aka mnemonic phrase. This article will be divided into several digestible parts. Ultimately, we will create one service for working with SSN, which includes the following microservices: Auth: for exchanging a JWT token for an internal identifier Generator: This gives the user addresses where he can get his parts of the key Shares: that is responsible for storing shares Metadata:  responsible for storing other information necessary for work Disclaimer: When I was creating this service, I was very much inspired by these guys: , so for production development, I would recommend them more and use a self-written service only if there is a security audit that will analyze each of your actions. Our company uses a self-written solution for several reasons, one is that it is better to have your own solution in conditions of modern uncertainty. We were audited by the Hallward company, and I hope that we will soon be able to open-source our implementation https://web3auth.io/safeauth.html In the first part (part 0), I want to dive into SSS in a basic way and show the basic formulas for working with polynomial mathematics using JavaScript as usual Part 1. will contain works with auth and generator microservices. We will change the user JWT token into our token, check some credentials for using our service, and choose where they will be stored user shares. Part 2. In this chapter, I’m going to dive into the storage part of our service First and most important - safely storing user's share into the blockchain Second, store other user's data into metadata microservice, aka blockchain 2. Principles Shamir's Secret Sharing (SSS), developed by Adi Shamir in 1979, is a cryptographic method that divides a secret into multiple parts, known as "shares." The fundamental idea behind SSS is that the secret can only be reconstructed when a sufficient number of these shares are combined. Here's a breakdown of how it works: : The process begins with creating a polynomial of degree , where is one less than the number of shares required to reconstruct the secret (known as the threshold). For example, if the threshold is 3, a polynomial of degree 2 (quadratic polynomial) is created. The secret is embedded as the polynomial's constant term (coefficient a_0), and the other coefficients (a_1 to ) are randomly generated. Polynomial Construction d d a_d : The polynomial is then evaluated at several points (other than zero) to generate the shares. Each share consists of two parts: the point at which the polynomial is evaluated (x-value) and the corresponding value of the polynomial at that point (y-value). For a threshold of , at least distinct points are chosen, and their corresponding polynomial values are calculated, forming shares. Generation of Shares n n n : These shares are distributed to the participants. No single participant can reconstruct the secret with their share alone. Distribution of Shares : When it's necessary to reconstruct the secret, a minimum of shares (as per the threshold) is brought together. The original polynomial is reconstructed using these shares, typically using a method like Lagrange interpolation. Reconstruction of the Secret n : Once the polynomial is reconstructed, the secret can be found by evaluating the polynomial at zero, which gives the constant term of the polynomial – the original secret. Retrieving the Secret Key Properties of SSS: : The threshold can be set according to the level of security needed. The secret can only be reconstructed if the threshold number of shares is combined. Threshold Flexibility : As long as the threshold is not met, even having access to −1 shares gives no information about the secret, assuming the polynomial coefficients are chosen randomly and securely. Security n : Loss of some shares does not compromise the entire system. The secret can be reconstructed if the threshold number of shares is available. Error Tolerance : Since the secret is not stored in a single location but instead distributed across multiple shares, the risk associated with a single point of failure is mitigated. No Single Point of Failure SSS is beneficial when security and reliability are paramount, such as securing cryptographic keys, safeguarding access to critical digital assets, or other cases you can imagine yourself. Formulation of the problem About number schemas: we can use different threshold values, but we need to know that the more parts of the key we create, the more likely a hacker will obtain the required number of key parts and assemble the original key. In our service, we will use the following schemas for storing data: On the user’s side, we will use scheme 3-2. This means that the private key will be divided into 3 different parts with indexes. And to restore the original private key, we need at least 2 of them. For further convenience, I suggest using the following names for our 3 parts: Social share: this share will be again divided into some parts and stored between different share nodes User share: this share should be stored on the user side (for example, if we use a browser, it can be localStorage or different storage), and we don’t need to encrypt it cloud share. This share can be saved everywhere by a user. We can present this share as a mnemonic phrase or store it on the web, but before we do it, we need to encrypt this share with a password or a different method that allows us to get the original value for the share. As mentioned, the user needs only 2 of 3 shares to work with a private key. For example, if a user has “user share” and “cloud share”, he doesn’t need to get “social share” for work, or if he restores on a new device or browser, he needs “social share” and “cloud share” On the backend for “social share” we will use 5-3. This means that we divide social share into 5 parts, and to restore the original key, we need only 3 of them. And all of them will be saved on different storages. As has been said earlier, our service is built from 4 microservices: Auth, Generator, Shares, and Metadata. Shares service can be stored by different participants of our service. In a perfect world, it should have different providers for deploy different storage like PostgreSQL, Ethereum smart contract, and others (in our solution, we will use only smart contracts), But no one is limited to choose their own storage. How it works First, users need a JWT token; for example, it can be taken from auth with Google or Apple auth services. After we get JWT, we exchange it for an internal JWT token. Why so hard? Good question. One of this service's central ideas is decentralization, which applies to the blockchain and the service for storing private key shares. However, we are not going to share the user's credentials with external services, and for this reason, we change the actual identifiers to internal. Also, we checked the credentials that only allowed OAuth providers to be limited. Now, we will check whether there is a saved key; if not, we suggest creating it. After creation, we divide one of the parts into five according to the same principle and distribute them between services and save the critical index, save another part, the locale, and offer the third part to be held somewhere by the user (there are a lot of options on how this can be done) If we understand that the user has already saved his private key, go to the shares service and get a list of services where the user shares and their indexes are stored. Get shares. After Lagrange interpolation, we have the first part of the share. But we don’t know its index. Here, the metadata service comes to our aid, from which, based on the key we receive, we will receive the index of this very key. The next step is to find the locally stored part or ask the user to provide it. We restore the original private key if we receive the required number of critical parts. A little bit of code Initially, I did not plan the code for this part of the article, but I still decided that the essential functions for working with Lagrange interpolation would look very nice here since it underlies the entire project. export class Polynomial {
    shares: BN[];
    polynomialId: string;

    static initialize(
        privateKey: BN | Buffer | null,
        threshold: number,
    ) {
        const pk = privateKey ? privateKey : randomBytes(32);

        const shares = [new BN(pk)];

        for (let i = 1; i < threshold; i += 1) {
            const share = randomBytes(32);
            shares.push(new BN(share));
        }

        const polynomialId = keccak256(...shares.map(bn => bn.toString()));

        return new Polynomial(shares, polynomialId);
    }

    static fromShares(shares: Share[]) {
        const unsortedPoints = shares.map<PolynomialPoint>(s => ({
            x: new BN(s.shareIndex, 'hex'),
            y: new BN(s.share, 'hex'),
        }));
        const sortedPoints = pointSort(unsortedPoints);
        const polynomial = generateEmptyBNArray(sortedPoints.length);
        for (let i = 0; i < sortedPoints.length; i += 1) {
            const coefficients = interpolationPoly(i, sortedPoints);
            for (let k = 0; k < sortedPoints.length; k += 1) {
                let tmp = new BN(sortedPoints[i].y);
                tmp = tmp.mul(coefficients[k]);
                polynomial[k] = polynomial[k].add(tmp).umod(curveN);
            }
        }

        const polynomialId = keccak256(...polynomial.map(bn => bn.toString()));

        return new Polynomial(polynomial, polynomialId);
    }

    constructor(shares: BN[], polynomialId: string = '') {
        this.shares = shares;
        this.polynomialId = polynomialId;
    }

    getPrivateKey(): BN {
        return this.shares[0];
    }

    getShare(x: string | BN): Share {
        const tmpX = new BN(x, 'hex');
        let xi = new BN(tmpX);
        let sum = new BN(this.shares[0]);
        for (let i = 1; i < this.shares.length; i += 1) {
            sum = sum.add(xi.mul(this.shares[i]));
            xi = xi.mul(tmpX);
        }
        return {
            share: sum.umod(curveN)?.toString('hex')?.padStart?.(64, '0'),
            shareIndex: tmpX.toString('hex'),
            polynomialID: this.polynomialId,
        };
    }
}

const pointSort = (innerPoints: PolynomialPoint[]): PolynomialPoint[] => {
    const pointArrClone = [...innerPoints];
    pointArrClone.sort((a, b) => a.x.cmp(b.x));
    return pointArrClone;
};

const generateEmptyBNArray = (length: number): BN[] =>
    Array.from({length}, () => new BN(0));

const denominator = (i: number, innerPoints: PolynomialPoint[]) => {
    let result = new BN(1);
    const xi = innerPoints[i].x;
    for (let j = innerPoints.length - 1; j >= 0; j -= 1) {
        if (i !== j) {
            let tmp = new BN(xi);
            tmp = tmp.sub(innerPoints[j].x).umod(curveN);
            result = result.mul(tmp).umod(curveN);
        }
    }
    return result;
};

const interpolationPoly = (i: number, innerPoints: PolynomialPoint[]): BN[] => {
    let coefficients = generateEmptyBNArray(innerPoints.length);
    const d = denominator(i, innerPoints);
    if (d.cmp(new BN(0)) === 0) {
        throw new Error('Denominator for interpolationPoly is 0');
    }
    coefficients[0] = d.invm(curveN);
    for (let k = 0; k < innerPoints.length; k += 1) {
        const newCoefficients = generateEmptyBNArray(innerPoints.length);
        if (k !== i) {
            let j: number;
            if (k < i) {
                j = k + 1;
            } else {
                j = k;
            }
            j -= 1;
            for (; j >= 0; j -= 1) {
                newCoefficients[j + 1] = newCoefficients[j + 1]
                    .add(coefficients[j])
                    .umod(curveN);
                let tmp = new BN(innerPoints[k].x);
                tmp = tmp.mul(coefficients[j]).umod(curveN);
                newCoefficients[j] = newCoefficients[j].sub(tmp).umod(curveN);
            }
            coefficients = newCoefficients;
        }
    }
    return coefficients;
}; Main class is which have 2 static methods: Polynomial : Creates a new polynomial with a specified number of shares. If is not provided, it generates a random one. Each share is a random 32-byte number, and the is computed using hash of the shares. initialize(privateKey, threshold) threshold privateKey polynomialId keccak256 : Constructs a polynomial from given shares. It sorts these shares, performs polynomial interpolation, and computes a . fromShares(shares) polynomialId in current scheme used for create unique identifier of our shares polynomialId And 2 Instance Methods: : Returns the first share, which is presumably the private key. getPrivateKey() : Computes and returns a specific share of the polynomial, given an input . getShare(x) x Helper Functions: : Sorts an array of objects based on their values. pointSort(innerPoints) PolynomialPoint x : Generates an array of objects initialized to zero, of the specified . generateEmptyBNArray(length) BN length : Helper for calculating the denominator in the Lagrange polynomial interpolation. denominator(i, innerPoints) : Computes the coefficients for the Lagrange interpolation polynomial for a given point. interpolationPoly(i, innerPoints) I understand that so far it all looks quite crumpled and chaotic, but still at least something =) For a better understanding of the theory, I recommend taking a look at (or another favorite source of information) Wikipedia Conclusion In this article, we took a superficial look at the operating principle of the future service and determined the scope of work that needs to be done in the following articles (tentatively, there will be two more) See you next time =)

Utilizing the Mechanics of Shamir's Secret Sharing Service

BENGALURU, India, November 2nd, 2023/Chainwire/-- (IBW), the country’s flagship series of blockchain and Web3 events held in Bangalore from Dec.4-10, is thrilled to announce the speaker lineup for the main IBW Conference. India Blockchain Week The conference’s headline speakers include Polygon Co-Founder Sandeep Nailwal, Aptos Co-Founder Mo Shaikh, Ava Labs Founder & CEO Dr. Emin Gün Sirer, TRON Co-Founder Justin Sun, and The Sandbox Co-Founder Sebastien Borget. Additional notable speakers will be Rene Reinsberg (Co-Founder of Celo) Prabhakar Reddy (Co-Founder of FalconX), Aniket Jindal (Co-Founder of Biconomy), Zhen Yu Young (Co-Founder of Web3Auth), Irene Wu (Head of Strategy at LayerZero), Manish Agarwal (CEO at IndiGG), Dr. Kang Li (Chief Security Officer at Certik), Simon Kim (CEO & Managing Partner at Hashed), Kelvin Koh (Co-Founder & Managing Partner of Spartan) among many others. Taking place at the Sheraton Grand in Bangalore on December 6-7, the IBW’23 Conference will have 100+ innovators, entrepreneurs, decision-makers and thought leaders across the entire spectrum of the blockchain industry engaged in keynote speeches, panel discussions, fireside chats, and moderated debates. For example: Sandeep Nailwal will engage in a fireside chat, discussing the current progress and future of Polygon 2.0, and sharing insights about the Indian Web3 ecosystem Mo Shaikh will deliver a keynote speech focused on the Move ecosystem and how Aptos enhances scalability and speed to enhance user experience Dr. Emin Gün Sirer will participate in a fireside chat, discussing strategies for fostering Web3 adoption through subnets and Avalanche's India strategy. Justin Sun will have a virtual fireside chat, delving into general crypto trends and offering perspectives on global regulation, stablecoins, and the Tron ecosystem. Sebastien Borget, in his keynote speech, will explore the future of the Metaverse and how brands can unlock value in digital worlds and their massive plans for India. “India is taking full advantage of Web3 technology across industries like social media, entertainment, commerce, and open financial systems”, said Mo Shaikh, Co-Founder & CEO of Aptos Labs. “The Aptos India ecosystem, growth and community is already expanding on a daily basis faster than most others. Our global enterprise partners are taking notice of the blend of market maturity and innovation happening across the country. We are dedicated to the expansion of Web3 in India and look forward to Aptos being a catalyst for the decentralized movement.” Besides the two-day headline conference, the week-long Web3 festival will feature other prime Web3 events such as ETHIndia, Polygon Connect, Polkadot Pulse, FILBangalore and many more. This is a unique opportunity to engage with emerging talent, attract new developers to the blockchain arena, and expand the blockchain ecosystem in India. "We're launching India Blockchain Week (IBW) because we see the synergy between India and Blockchain as not just a game-changer, but our collective destiny," said Tak Lee, CEO of Hashed Emergent, host of the India Blockchain Week (IBW) Conference. About India Blockchain Week (IBW) India Blockchain Week (IBW) is a series of blockchain and web3 events, spanning from 4-10 December 2023 across Bangalore, India. IBW is a week-long array of 50+ web3 events, including flagship events such as the headline IBW Conference, ETHIndia, Polygon Connect, Polkadot Pulse, FILBangalore and many other side-events, networking events, workshops, parties etc hosted by Indian & global blockchain industry stakeholders. The IBW Conference is the two-day headline event anchoring India Blockchain Week (IBW) on 6-7 December 2023 at the Sheraton Grand, Bangalore and hosted by Hashed Emergent - a team and brand dedicated to accelerating the mass adoption of Web3 in India. For more information about IBW, visit: | | | Website Twitter LinkedIn Telegram Contact Irshad Ahmed gm@indiablockchainweek.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program . here

Sandeep Nailwal, Mo Shaikh, Dr. Emin And Justin Sun To Speak At India Blockchain Week

সন্দীপ নেইলওয়াল, মো শেখ, ডাঃ এমিন এবং জাস্টিন সান ইন্ডিয়া ব্লকচেইন সপ্তাহে বক্তৃতা করবেন

Sandeep Nailwal, Mo Shaikh, Dr. Emin und Justin Sun sprechen auf der India Blockchain Week

Sandeep Nailwal, Mo Shaikh, Dr. Emin y Justin Sun hablarán en la India Blockchain Week

Sandeep Nailwal, Mo Shaikh, le Dr Emin et Justin Sun prendront la parole à la semaine indienne de la blockchain

संदीप नेलवाल, मो शेख, डॉ. एमिन और जस्टिन सन इंडिया ब्लॉकचेन वीक में बोलेंगे

サンディープ・ネイルワル氏、モー・シャイク氏、エミン博士、ジャスティン・サン氏がインドブロックチェーンウィークで講演

Sandeep Nailwal, Mo Shaikh, Dr. Emin 및 Justin Sun이 인도 블록체인 주간에서 연설합니다

Sandeep Nailwal, Mo Shaikh, Dr. Emin e Justin Sun falarão na India Blockchain Week

Сандип Наилвал, Мо Шейх, доктор Эмин и Джастин Сан выступят на Неделе блокчейна в Индии

Sandeep Nailwal, Mo Shaikh, Dr. Emin ve Justin Sun Hindistan Blockchain Haftasında Konuşma Yapacak

Sandeep Nailwal, Mo Shaikh, Tiến sĩ Emin và Justin Sun sẽ phát biểu tại Tuần lễ Blockchain Ấn Độ

Sandeep Nailwal、Mo Shaikh、Emin 博士和孙宇晨将在印度区块链周上发表演讲

Content Overview What is dApp? What client-side technologies should be used for a dApp? Which type of domain should you choose? Authentication: MetaMask's Dark Side Blockchain Selection: Which Chains Are Best for dApps? Funding Your Idea Through Grants What is dApp? The commonly accepted definition of a is, in short, an application that can operate autonomously using a distributed ledger system. At first glance, it seems straightforward. But, when you begin to question and list examples of dApps, it appears most dApps wouldn't qualify. It may even seem as if true dApps don't exist. dApp If one developer tried to explain to another what a dApp is in 2023, they'd probably say, "Well, it's like a website that calls various APIs working with blockchain." Just like that, the magic of the term 'dApp' would vanish. The other developer would think, "What's the big deal? Why so much fuss about it?" The reason is that the genuine concept of dApps has long been sacrificed for user convenience. Originally, the term implied that every instance of the application runs on the user's device. You'd fetch wallet balances from your node, and you'd send transactions from it as well. The application itself should be stored on a distributed storage system resistant to censorship, outages, and attacks. All user-generated data should also be stored in such storage or directly in a blockchain smart contract. It's a captivating concept, but it clashes with reality. Blockchain data can weigh gigabytes or even terabytes. Decentralized storage requires specific software and space for distributed data, isn't as fast as AWS, and often needs specialized browsers. Interacting with smart contracts costs money in cryptocurrency, and purchasing it isn't straightforward for first-timers. Then, factor in the complexity of setup, the need for specialized knowledge, ample free time, and the myriad of blockchains out there. So, dApp developers started offloading the most complex parts for users to separate services, interfacing with them solely via APIs. Now, almost every blockchain has its API. This means dApps have to store settings for each network to cater to more users. While APIs for distributed storage exist, hosting the dApp on them isn't efficient. Most solutions can't compete with web2 in speed and convenience. Hence, such storage systems are only used for tasks where response time isn't a priority. Even on Hackernoon, Arweave is used only for backing up articles. What client-side technologies should be used for a dApp? Well, if we aim to reach the maximum number of people in 2023 and 2024, then client-side web technologies are the way to go for . True, backend technologies like PHP and Python won't cut it, but any framework based on JavaScript/Typescript will do the trick. You can pick from the top 3 frameworks: React, Angular, or Vue.js. However, in my experience, Web3 components for Angular are rarer. My personal choice is React with Typescript. Of course, nobody's stopping you from using plain JavaScript, but why would you? creating a dApp Further, to interact with smart contracts, you'll need some kind of library. The most popular ones are Web3.js and ethers.js. In my opinion, both aren't the most elegant. Their APIs frequently change, and code examples older than a year might not work straight away. My personal pick is ethers.js. Its structure feels more intuitive to me, and compared to Web3.js, the solutions tend to be more concise. In the documentation of various projects, examples are usually provided for at least these two libraries. First and foremost, create an empty project (React + Typescript). npx create-react-app project-name --template typescript Navigate to the project directory. cd project-name Install ethers. This will ensure you have the most up-to-date version. Keep in mind that older examples from the internet might not work without adjustments. npm i ethers Which type of domain should you choose? No, I'm not talking about top-level domains like .com, .org, and the like. I'm discussing whether one should opt for decentralized domains instead of traditional ones. Yes, domains can be decentralized, too. Instead of the usual top-level domains, you might come across ones like .eth, .nft, .wallet, .crypto, and .go. Unfortunately, using them in popular browsers (like Chrome and Safari) without additional extensions won't work. Various companies have been trying for years to establish a domain zone that functions both in web2 and web3. So far, agreements have only been reached with less popular browsers like Opera and Brave. In these browsers, Web3 domains work. So, if your target audience primarily uses the most popular browsers, the choice is clear: you need a Web2 domain. However, if your application becomes popular, domain squatters might purchase a domain with your project's name. When the Web3 revolution takes place and domains become accessible in all browsers, these squatters will likely demand a hefty price for that domain. From this, it emerges that Web3 domains might be worth purchasing as a safeguard against squatters or for a hardcore audience using specific browsers. Furthermore, such domains can serve as an alternative to unreadable wallet addresses. Instead of a complex address like 0x5301b241879e66EC45fD284D3D97A5C51472D6f3, you could use a domain like “mydapp.crypto” to send and receive funds. Authentication: MetaMask's Dark Side Currently, MetaMask stands as the most popular browser extension for storing people's wallet private keys. The private key is the most crucial element - "Not Your Keys, Not Your Crypto.” Entrusting such a vital component to anyone is a no-go, making it preferable to store it on one's device. MetaMask, in this context, allows users to keep their private key locally and doesn't share it with anyone, not even dApps, no matter how nicely they ask. Despite its millions of users, getting started with MetaMask isn't straightforward. One has to go through a myriad of not-so-simple steps to set up an initial empty wallet. And then an equal number of steps are required to fund that wallet. I can confidently say that the next billion users will opt for a different solution. But as of now, it's the industry standard, and . every dApp should support MetaMask But what if I told you there are over a hundred other wallets out there? It would be ideal to support those as well. But don't pull your hair out just yet! Solutions already exist that support all popular wallets. Typically, apart from browser extensions, these solutions also cater to mobile apps, significantly broadening the potential user base. Examples of services you can use are Web3Auth and WalletConnect. Blockchain Selection: Which Chains Are Best for dApps? If you delve into the website of nearly any blockchain project, you're often met with bold claims: their blockchain is the fastest, most user-friendly, cheapest, and boasts millions of users now or will very soon. So, with this vast array of blockchains and ecosystems, how do you pick the right one? In my view, the answer is clear-cut: if the blockchain is EVM-compatible, you're already halfway there. EVM, or Ethereum Virtual Machine, backed by the Ethereum Foundation, is a standard that any blockchain project can adopt. Critically, all tools for testing, debugging, deployment, linting, explorers, etc., will seamlessly integrate with this new chain. This means that if you create a dApp for one EVM-compatible project, it can, with minimal configuration, work across nearly all others. Sounds like magic, right? Regarding non-EVM compatible projects, for them, you must have a clear rationale. Recognize that targeting these chains may limit your user base, offer fewer tools, and present more unprecedented bugs. The smart contract languages also differ, sometimes drastically. Here are the languages used for smart contract development in the top 20 capitalization projects: Solidity, Plutus, and FunC. Each of these languages is tailored specifically for individual blockchains. Grasping each requires considerable time, as their operational principles vary substantially. when developing dApps Of course, you can architect your dApp to operate across a majority of these diverse chains. However, that's an advanced move and quite time-consuming. Straddling two worlds isn't always straightforward. Let's dive right back into building our dApp with the newfound knowledge at our disposal. For this walkthrough, I'll be using the Gnosis Chain as our EVM-compatible blockchain. It's an L2 network that boasts cost-efficient transactions. For several years now, I've deployed a public notes smart contract on it, allowing users to create textual notes under their usernames. You can find it at this address: `0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0`. To read data from this contract, you first need to instantiate a provider. A provider essentially acts as an RPC API to a specific blockchain node. The server delivering the data is already in sync with the blockchain network and provides the most up-to-date state. const provider = new JsonRpcProvider('https://rpc.gnosischain.com/'); To fetch data from our contract, we'll create an instance of `Contract` from `ethers`. const contract = new Contract('0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0', notesAbi, provider); If I had linked my contract address with a .eth domain, then you could access the contract like this. const contract = new Contract('myapp.eth', notesAbi, provider) In this instance, we're passing in my smart contract's address, the provider, and the ABI (Application Binary Interface). The ABI ensures that the node can interpret state data from binary correctly. The ABI content is quite detailed for this article, so I've moved it to a separate URL. Next, we need to prepare the username in the required format to use it for data retrieval: const usernameHash = keccak256(toUtf8Bytes('igor')); Then, you can fetch all the records I've saved in the smart contract like this: const items = await contract.getNotes(usernameHash); You can check out the entire code for `App.tsx` . here Also, a quick heads-up: In the example, I'm using a free provider. If you're scaling a dApp with a significant user base, it might not be suitable. In such cases, you'd either want to set up your node or opt for paid providers from services like Alchemy or Infura. Funding Your Idea Through Grants In the fast-paced world of dApps, innovative ideas can often operate at a loss for extended periods. It's great if you've got a plan to turn a profit swiftly and a few thousand dollars to sustain yourself in the meantime. But if you don't, fret not. Ideas with sound financial potential always catch the eye of venture angels and investors. But in the Web3 universe, innovation is additionally fostered through grants provided by major foundations such as Ethereum, Binance, and Optimism. These grants are often disbursed without any strings attached, either in phases or as a lump sum. Unlike venture capital, grants don't come with the business obligations typical of angel investors. Projects awarded grants from a specific foundation should, in the long run, positively impact that specific ecosystem. The conditions and allocated amounts vary from one foundation to another, with grant amounts ranging from hundreds to hundreds of thousands of dollars. These are often disbursed in the project's native tokens. To gauge if your project idea aligns with a particular grant program, study previously awarded grants and benchmark against your own. Do you think you can deliver something similar or even better? You're likely grant material. But bear in mind that securing a grant can be a long process. Despite being a fantastic avenue to bring your project to life, be prepared for stage to take weeks or even months. The stages you'll navigate are: each Application Preparation. Many grant applications are straightforward. You'll be detailing your idea and showcasing your team's expertise. Put forward a compelling pitch about both the project and the team. Lack of experience in Web3 might reduce your chances of securing a grant. Project Evaluation. After submitting your application, anticipate a long evaluation phase. The higher the grant amount requested, the longer the evaluation. Typically, you'll receive an approval or rejection email. However, some projects might ghost your application. A month post-submission, don't hesitate to follow up on the application status. And feel free to apply to multiple foundations. Some projects might even qualify for grants from various foundations. Just be wary of potential conflicts of interest and clarify the feasibility of securing multiple grants upfront. Contract Signing. Post-grant approval, you'll engage in a phase of document preparation and signing by all committee members. While you can often start working before the contract signing, there's no guarantee that the contract will get finalized. The hold-up isn't always on the foundation's end; sometimes, sanctions might prevent a grant's disbursement based on your citizenship or residency. Project Acceptance. Acceptance of your grant can be slow-paced. Every committee member will thoroughly vet your solution. Prep a top-tier demo of your project since some members might have less technical knowledge and will evaluate based solely on your demo resources: demo sites and video presentations. Grant Payout. Post a successful grant review, the approval decision goes to accounting. Here, too, payments can get held up, especially if multiple people's confirmations are required. Often, these individuals are engaged across various projects, not just grants. To obtain a list of nearly all projects offering grants, search for "List Web3 Grants" online. As you can see, if you have experience in web2 development, not all concepts in web3 will be clear at first. Many things might raise questions. Nevertheless, this article calls for a part 2, where we could build a full-fledged application using different networks, with the capability to store data in a decentralized manner, as well as interact with smart contracts either at the user's expense or the developer's. See you in the next part!

Dive Into dApps: Your Ultimate Guide to Start Crafting Them Today!

Crypto adoption is on the up – even amidst the bear market of 2022, the market saw an increase in wallets and transactions. In June 2023 we saw 15 million active wallets, more than twice as many as two years ago when prices were still elevated. Such interest spawns out of a number of reasons – from lower fees, higher speed, and better security, to its nature as a shield against the forces of inflation and its provision of greater opportunities on the global stage. But, we’re still in the early days of the development of the crypto industry. If we compare the growth rates of Internet users and crypto users, the resulting trend will be very similar. If the crypto industry develops effectively, simultaneously solving all the problems that place the masses in adoption, then by the end of this decade we should theoretically expect the first billion crypto users. Nevertheless, noting the benefits, adoption isn’t as widespread as we should expect, especially in the non-custodial market. The reason? The gaping education gap. Blockchain technologies are simply very difficult to get your head around. In order to use an EOA, or an ‘Externally Owned Account’ such as an account from wallet, the average user needs to understand terms such as ‘seed phrase’, ‘private and public keys’, ‘smart contracts’, ‘gas fees’ – there’s no getting around it either, as if mistakes are made, funds are lost. Metamask Sad stories about self-custody wallets https://twitter.com/david_e_olsson/status/1592971853962039296?embedable=true https://twitter.com/MissBlackOG/status/1333805445685899265?embedable=true https://twitter.com/boshen1011/status/1595265219898789888?embedable=true As a result, for years, the community has been on a quest for simplification. Indeed, now, with the concept of ‘Account Abstraction’, we’re almost there. That’s why, today, we’ll be exploring the wheres, the whats, and the whys, while evaluating the two different categories of solutions. What is Account Abstraction? As we covered briefly, the main barrier to the widespread adoption of cryptocurrencies lies in their complexity of use. EOAs are effectively public-private key pairs, where the user acts as both the ‘Signer’ of transactions and the ‘Account’. They’re responsible for both the validation and execution of transactions – in other words, that’s a lot of weight to put on the old lady looking to send money to her grandson for his birthday. Aside from the amount of conceptual knowledge that is needed to perform a transaction on the blockchain, use needs to be void of error. As there’s no third-party custodian to deal with lost passwords and two-factor authentication, if the password is lost, the funds are lost in tandem. As such, most people who are interacting with the blockchain do so on a custodian-only basis, instructing centralized platforms such as Binance to hold their private keys on their behalf. Of course, there are privacy concerns here – especially when we consider the recent FTX debacle. Centralization was never the dream of the blockchain, so a solution regarding the usability of non-custodial platforms has always been a priority. That’s where account abstraction comes in. In layman’s terms, this is the practice of decoupling the relationship between the account holding the assets and the signer by making the account itself a smart contract. Of course, such an idea isn’t new, and was always on the Ethereum roadmap, being proposed back in different EIPs since 2016. Recently, however, with EIP-4337 being announced in 2021, the dream is finally becoming a reality with application layer solutions. Any dApp developer would be able to utilize the proposal to do things such as: sponsoring user transaction fees; enabling additional security features such as on-chain transaction monitoring; utilizing social logins to introduce non-custodial guardians and providing account recovery. Recently, on March 2nd, 2023, the community deployed the smart contracts necessary for the implementation of EIP-4337 to the main Ethereum network. Then major infrastructure players such as Alchemy, Biconomy, Gelato Network and etc. released core account abstraction infrastructure components. Moreover, with the advent of advanced layer-2 mechanics, ZK-Rollup solutions such as StarkNet and ZKsync offer native account abstraction on the protocol layer. In theory, account abstraction and the flexibility it provides is an ideal solution to the aforementioned barriers to blockchain entry. However, there’s one main reason why a solution hasn’t been crowned, and that lies in the increased security risks. The extensibility of transactions increases the attack vector surface area, owing to the fact that every component ought to be secured individually and holistically. Nevertheless, every day, our heroes crawl closer to the finish line, and the risks facing account abstraction are diminishing day by day. As such, it’s worthwhile digging deeper into the kinds of solutions available. Application-level solutions on L1s: smart contract plus off-chain infrastructure We’ve spoken to some degree regarding the Ethereum Improvement Proposals that change the way the network works. Since 2016, the idea of Account Abstraction has certainly been a desirable integration. Notably, in 2018, smart-contract wallets were introduced to secure user assets. At this point, social recovery became possible for the first time, with on-chain fraud monitoring – all without providing custody to a third party. In 2020 with EIP-2938, a new kind of transaction was developed that would enable smart contracts to act as top-level accounts. Not long after came EIP-3074 which made existing EOAs behave similarly to smart contracts, allowing users to simply delegate EOA control to a smart contract. Then, in 2021, EIP-4337 hit the Ethereum roadmap, which is where we are today. The main idea of the proposal was to standardize the off-chain infrastructure required to write and operate smart-contract wallets. Notably, with a clear separation of validation and execution when it comes to non-custodial user actions on the blockchain. Source: The road to account abstraction by Vitalik Buterin So, what’s going on behind the scenes when it comes to EIP-4337? Firstly, the transaction pathway involves the UserOperation being sent to a high-level mempool (effectively, a queue where transactions are sorted and stored before being added to a new block). Then, a bundler wraps up a group of UserOperations into a bundle transaction, which is then sent to the EntryPoint contract with fees being paid by the bundler. Then, the EntryPoint contract does two things. First of all, it verifies the target wallet’s transaction and then it executes the call. As we looked at it, there’s a clear separation between validation and execution here – something incredibly important for account abstraction. Such an approach can be used for building new-generation crypto wallets for EVM blockchains, where users will be able to take advantage of advanced security features such as social recovery, key-changing, and etc. multi-sig Using a real-world example, Safe Wallet by Gnosis – a multisig smart contract wallet that runs on EVM blockchains. The wallet itself requires transaction confirmation from not one but several wallet holders, each holding a different signature. It is worth noting that Safe is probably the very first smart contract wallet that has become widespread and at the moment about 60 billion assets are stored in more than 3 million wallets. The official Safe wallet cannot be called a very powerful account abstraction wallet that implements all the features that this new concept gives, it basically has only multi-sig functionality. Safe positions itself more as an open protocol on the basis of which it is possible to build a next-generation crypto wallet thanks to its extensible design. More recently, Safe has supported EIP-4337 as a standard and released the Safe {Core} account abstraction SDK for external developers. However, application-layer technologies on the Ethereum mainnet come with noticeable drawbacks. Smart contracts, for example, don’t just expand the applications of blockchain technology, but they also increase the surface area for attack. These contracts are usually written in a high-level language such as solidity, before being compiled into bytecode and deployed to the blockchain by the contract owner, where they’ll run on various virtual machines. The complexity means that novel attack vectors arise, increasing the likelihood of transaction order dependence attacks, false top-up attacks, and replay attacks – all usually occurring on the application layer. Secondly, since the entire Ethereum ecosystem is built around EOAs, many Dapps are incompatible with smart contract wallets. This is largely a result of smart contract wallets being seen somewhat as ‘second-class’ citizens on Ethereum. Account abstraction infrastructure for application level (Smart Account Contract, Bundler, Paymaster, SDK) Biconomy (Smart Account Contract, Bundler, Paymaster, SDK) StackUp (Smart Account Contract, SDK) Safe (Key management) Web3Auth Wallets built on top (based on Safe) Safe (based on Safe) Worldcoin Ambire Sequence (beta, based on Safe) Pluser (beta, based on Safe) Sout wallet And more… Protocol-level solutions on L2s: native account abstraction The solutions to application layer vulnerabilities lie in the development of a layer-2 solution, designed to be used with account abstraction. In other words, a sidechain that can move the process of account abstraction to the protocol layer. StarkNet and ZkSync are fantastic examples of L2s with native account abstraction realization inspired by erc-4337.  The main difference from EIP 4337 on L1 is that native accounts here are first-class citizens of the protocol. Let's deep dive into the implementation of account abstraction on StarkNet. Just like with EIP 443, there’s a meta to validate each transaction. Indeed, the function makes sure that any submitted transaction was initiated by the account owner, and won’t take up any additional resources during execution, while the function abstracts away the remaining actions performed by a transaction. Validate execute Another key task of these layer-2 solutions is to verify off-chain signatures – something that was proposed on the mainnet with EIP-1272. Indeed, that’s something that StarkNet does quite well with Argent X, a browser wallet based on StarkNet’s existing infrastructure – the account in the signed data coming from off-chain messages makes sure that if multiple account contracts are using the same key, the signature requested by a dApp for a specific account cannot be used for the purpose of alternate account authentication. As a matter of fact, the app is the first wallet to exist on StarkNet, and has a browser extension for Chrome and Firefox. It’s multi-account, enables users to send and receive NFTs, and is 100% . In layman’s terms, Argent X realizes the benefits of the StarkNet infrastructure on the front end. open source Moreover, just like application-layer infrastructure, these layer-2 applications also enable the connection of guardians, where accounts can be re-programmed to suit new keys. Social recovery is 100% non-custodial as you can decide who the guardian is and change it any time you wish. There are also some fantastic benefits when it comes to gaming. For example, session keys being available with logic customizability means that variables such as time and contracts to be interacted with can be altered depending on the use case. Native account abstraction implementation ZKSync Starknet Wallets built on top (ZkSync and Starknet) Argent (beta, ZkSync) Raise Finance The current state of account abstraction It is difficult to count how many account abstraction wallets there are on the market, but I found 2 Dune dashboards with statistics. The first one features 400k+ ERC-4337 wallets from different EVM networks (Base, Avalanche, Optimism, BSC, Arbitrum, Ethereum, Polygon), the second shows that there are 4m+ Safe wallets from different EVM networks (all supported by Safe chains). Source: https://dune.com/niftytable/account-abstraction Source: https://dune.com/safe/all Speaking about Safe. Most recently, the sensational Worldcoin project released its World app to the public with a built-in non-custodial crypto-wallet and World Orb device through which the identity verification process is organized around the world. Thus, in just a few weeks, they onboarded 2+ million users who received proof-of-personhood Id from Worldcoin to their crypto wallets created in the World app. The project developers decided to apply the concept of account abstraction in the development of the World App. Under the hood, this smart contract wallet uses Safe{Core}, an account abstraction stack by Safe. Now, through account abstraction, they organize only a gas-less experience for their users, but in future releases, they are going to support account recovery and other interesting features that the AA concept allows them to implement. To date, the World App is the largest deployer of Safe wallets, among 4m+ Safe wallets, 1.5m was created by Worldcoin for their users. Source: https://dune.com/hashed_official/worldcoin-dashboard Considering the amount of infrastructure and the number of created smart wallets, the figure is not yet impressive, we will write off the fact that it is now a crypto winter and a certain maximum number of crypto users has been reached. But it cannot be denied that will be ready for the next bullish trend and the flow of new crypto users will be onboarded through account abstraction wallets, and not through EOA wallets. And I think the example of a Worldcoin launch will make account abstractions wallets even more popular. Final thoughts In terms of a conclusion – one thing is clear. solutions are in no way inferior to the mainnet Ethereum Improvement Proposals, and instead, largely build upon them. Much like layer-2 solutions are designed with greater speed and lower transaction fees in mind, native account abstraction with these features in-built are great alternatives to the shortcomings of the Ethereum mainnet. Layer-2 With crypto adoption increasing day by day, it’s important that we solve the problems associated with a confusing interface so that a bad taste is not left in the mouths of regulators and ordinary users alike. That’s why realizing true account abstraction – be it through the application-level powers of the Ethereum mainnet or the up-and-coming layer-2 projects that bring this concept to the protocol level – has never been more important for the widespread adoption of blockchain technologies. Lead image by on Unsplash Shubham Dhage

Account Abstraction: Solutions for L1 & L2 Layers and Current State of Adoption

অ্যাকাউন্ট বিমূর্ততা: L1 এবং L2 স্তরগুলির জন্য সমাধান এবং গ্রহণের বর্তমান অবস্থা

Kontoabstraktion: Lösungen für L1- und L2-Ebenen und aktueller Stand der Akzeptanz

Abstracción de cuenta: soluciones para capas L1 y L2 y estado actual de adopción

Abstraction de compte : solutions pour les couches L1 et L2 et état actuel de l'adoption

खाता अमूर्तन: L1 और L2 परतों के लिए समाधान और अपनाने की वर्तमान स्थिति

アカウントの抽象化: L1 および L2 レイヤー向けのソリューションと導入の現状

계정 추상화: L1 및 L2 계층을 위한 솔루션 및 현재 채택 상태

Abstração de conta: soluções para camadas L1 e L2 e estado atual de adoção

Hesap Soyutlama: L1 ve L2 Katmanları için Çözümler ve Mevcut Benimseme Durumu

Trừu tượng hóa tài khoản: Giải pháp cho các lớp L1 & L2 và tình trạng áp dụng hiện tại

帐户抽象：L1 和 L2 层的解决方案以及采用现状

Why NFTs? The use of non-fungible tokens (NFTs), sometimes also known as 'digital collectibles', in web2 games has been a hot topic in the gaming industry lately. NFTs are unique digital assets built using blockchain technology, offering several benefits for game developers and players. One of the biggest advantages of NFTs is that they can be used to create truly unique and valuable in-game items. In traditional web2 games, players often rely on in-game currency or other abstract forms of value to purchase or trade items. This can be frustrating for players, as it can be difficult to accurately assess an item's value or truly have ownership over it. NFTs, on the other hand, provide a transparent and verifiable form of ownership for in-game items. This gives players greater control over their virtual possessions and makes it easier to trade and sell items with other players. This can create more robust and active in-game economies, which can be a major draw for players. How can my game integrate NFTs? Despite these benefits, many game developers have been hesitant to adopt NFTs due to the steep learning curve. Blockchain technology can be difficult to understand and use, and it can be challenging for developers to integrate it into their existing games. Fortunately, several tools and platforms are making it easier for developers to experiment with NFTs, such as , , , and others. Ankr Altura Metalinq Chainsafe, , for example, is a blockchain-as-a-service platform that provides a suite of tools and services for developers who want to incorporate NFTs into their games. The platform offers a range of features, including a marketplace for buying and selling NFTs, a customizable wallet for storing and managing NFTs, and support for multiple blockchain networks. Ankr , on the other hand, is a platform that provides a range of API tools and services for developers who want to integrate NFTs into their games. The platform offers a range of features, including an NFT creator tool and a marketplace for buying and selling NFTs, while supporting several blockchain networks. Altura is a web3 gaming toolbox that helps game developers create non-custodial game wallets using state-of-the-art solutions like web3auth. The players won't even know they are using blockchain tech in the background or doing NFT transactions when buying and selling their in-game items. Metalinq In addition to tools and platforms like Ankr, Altura, and Metalinq, other solutions are making it easier for game developers to incorporate NFTs into their games. For example, is a platform that can remove the biggest friction for blockchain transactions - gas fees! Biconomy One of the key features of Biconomy is gasless transactions, which makes it easier for game developers to abstract away the complexities of blockchain even further. Biconomy can help enable meta-transactions, such that the onus of paying and dealing with gas fees falls on the game developer rather than the player, thus making it for a seamless UX end-to-end. Conclusively Using NFTs in web2 games can revolutionize how players interact with and value in-game items. While the technology can be challenging to understand and use, some tools and platforms are making it easier for developers to experiment with NFTs and see the benefits for themselves. As more and more games adopt NFTs, we can expect to see exciting developments and innovations in the world of online gaming.

NFT Tools for Building a web3 Game

Are JWTs really dead, or are they just misunderstood? I’ve seen quite a few articles lately suggesting that the advent of Web3 and the spreading usage of wallets will lead to users ditching traditional email/password-based account systems, and instead, logging in using their wallet. To be honest, after using a few dApps, the super simple workflow of a click or two of your wallet that pops up is indeed a superior experience. Many of these articles go on to say “yay we don’t need JWTs anymore!”. This is where I disagree. JWTs, while a bit confusing at first, are incredibly useful for backend engineers, especially those of microservice systems. , considering that these systems - a great number of them - already exist and already integrate with JWTs! Ethereum is great and all, but we really do not need to reinvent the wheel. It’s good to be able to continue using the same backend tools you are used to when you need to. Especially Logging in with MetaMask proves it’s you - but how do you prove to future API calls it is you? The “screw-JWT” crowd suggests using simple Session IDs, but this is a step backward to the early 2000s, mind you, when simple layered architectures were the standard, which did not have the complexities of today’s backend systems. Unfortunately, Session IDs can not be verified without an additional round trip to the database to determine whether or not the Session ID granted belongs to a valid session. This means when the backend service receives the request that contains the session ID, it then makes a request itself to the auth server asking “is this active” - and then every other service in the Microservice system asks the same. If there are several services involved, that could be several additional round trips to the auth service. In order to remedy this situation, cryptographic experts got thinking. What they came up with was JWTs - now part of the OpenID standard, you know, the one that Keycloak, Auth0, and others help you to implement. JWTs, y’all The solution was to grant a set of tokens - JSON Web Tokens to be precise. That set consists of an , a , and an . These tokens were then “signed” by a secret - usually called the . Signing, just so we’re on the same page, is a cryptographic hashing algorithm, in the case of JWTs – usually (the default for Auth0).  In the case of the is used as the input and hence, becomes the key needed to successfully decipher that hash - or “verify” it.  With and a public/private key pair are used, i.e. signed by private key, and verified with public key on the client. AccessToken RefreshToken IdToken ClientSecret HS256 HS256 ClientSecret RS256 ES256 This means if a backend service receives one of these tokens, and it knows the , it can verify that the token was actually issued by the auth service which signed that token. The token used when attempting to access a backend service is the . These tokens specifically contain information about who the user is as well as their “claims”, or in other words, what they are allowed to do formatted for the system that cares about it. ClientSecret AccessToken For microservice systems, this means each service that cares about verifying identity just needs to know about the as they can verify the JWT is authentic using it, rather than a roundtrip to the database. In a system with many microservices, this can reduce many additional round trips to the database, making the entire system more scalable. ClientSecret Access tokens, if stolen, can be used maliciously, and for that reason, it’s important to take the appropriate precautions when designing a system to use them. The set of precautions, on top of signing and verifying the tokens consist of: minimum Setting an expiration date on the Access Token JWT of 5-15 minutes and making sure tokens are not expired when received Don’t store the Access Token except for in memory Issue Refresh Tokens that can be stored and sent to a server for verification, and refreshed along with using the and that issued it. ClientSecret ClientId Only use when transmitted over TLS connections (HTTPS) Use HTTP Only cookies so they can not be modified on the browser side CORS settings A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. - , note: bits for HS256. RFC7518 Auth0 uses 512 A confidential client needs an intermediary server, such as Node.js - this server is a proxy to the auth service so the client need not know about the client secret. A public client exposes the client secret, and there isn’t a proxy server between the browser and the auth service. This can be restricted further with CORS settings so only requests from certain domains are allowed. Additional precautions include: Use Rotating Refresh Tokens – each one can only be used once. When used it is exchanged for a whole new set of tokens, and the exchanged refresh token is revoked. If this strategy is employed it’s worth noting that users with a poor internet connection can sometimes not receive the response to the refresh request and try again. For this reason, a short grace period of 30 seconds or so will allow for them to hit refresh and try again. Allowing user to revoke all of their existing refresh tokens by logging out. And probably more - for example, if you detect someone attempting to use a revoked refresh token, you could revoke all of that user’s active refresh tokens. All of these precautions, admittedly, can make getting it right a bit tough. There’s a lot to understand. There’s also usability concerns. A user becoming logged out of your site every 5 minutes would feel pretty annoying to them. To avoid this, a silent refresh loop must be implemented in the consuming application to continually refresh the token set. That said, on the other side of getting it right, is being able to securely integrate with all of your backend systems in a scalable way, as well as many existing tools - such as , which can autogenerate all your APIs for you based on a connected Postgres’ DB schema. Thus, being able to integrate easily with existing tooling can save a lot of development time. Hasura If you use OpenId already, it’s likely you already have these things in place. It is, after all, an authentication standard. So how can we keep the convenience of using JWTs in a Web3 and login with MetaMask world? JWTs and Web3? Let’s start by understanding the OpenId authentication flow used for SSO. You visit a website and want to login with your account - you click the login button You are redirected to the SSO login page - you login with an email/username and password You are redirected back to the original application with a set of JWTs which are stored appropriately and used in silent refresh background flows. In the web3auth world, we are replacing step two with using your wallet’s private and public key pairs to sign a challenge. The redirect is not needed or desired. You visit a website and want to login with your account - you click the login button You are receive a challenge from the auth server which pops open your wallet asking you to “Sign” the challenge. Press sign. The auth server verifies your signature and issues you a set of JWTs which are stored appropriately and used in silent refresh background flows. We’re simply replacing the SSO style redirect flow with a challenge that is signed by your wallet. The flow after receiving the tokens remains the same as OpenID. That means you could for example, switch from using OpenID to using web3auth with a JWT issuing server, and nothing about using those tokens after they are granted would need to change. All your existing backend integrations with tools like Hasura remain exactly the same. This is exactly what I want as a Full Cycle developer. I don’t want to reinvent the wheel. I want to replace OpenID with web3auth and still be able to use all of the powerful tools that I am used to. Unfortunately, I couldn’t find a web3auth server that did this as well as the security precautions. I found a few projects demonstrating techniques in the process, but not the whole flow end to end. So I got to building… I built this here auth server: https://github.com/CloudNativeEntrepreneur/web3auth-service And this here integration to go with it, that implements all the things - silent refresh, yada yada - all those things I mentioned above: SvelteKit https://github.com/CloudNativeEntrepreneur/sveltekit-web3auth Of course if there was gonna be a GraphQL client and example, then there needed to be a GraphQL server and database as well, so I also provided examples of that: + https://github.com/CloudNativeEntrepreneur/example-hasura https://github.com/CloudNativeEntrepreneur/example-readmodel This example uses the and , so all you need to do is declare your DBs and describe your schema in YAML, and Hasura will autogenerate all the GraphQL APIs you need. AND, I made the auth server with Hasura in mind, so it has the proper claims to integrate with Hasura's RBAC and permissions, which are quite robust. Zalando Postgres operator SchemaHero And of course, you need a place to run all that, and so, a local dev cluster that sets up all the tooling like istio, and the operators, and SchemaHero for you! https://github.com/CloudNativeEntrepreneur/local-dev-cluster But who knows how to even use all that? So that's why I made this repo: meta https://github.com/CloudNativeEntrepreneur/web3auth-meta Using that meta repo will clone all the projects you need down into the right places, and run them all together. Finally, to run all the projects together, you need tools installed, and installing tools is annoying - so I made this repo here that will install them all for you! https://github.com/CloudNativeEntrepreneur/onboard I also published on npm, and made a template out of a SvelteKit project that uses it and has GraphQL set up and integrated with authentication to a Hasura instance so when you're ready to make your own projects, you can use that as a template! sveltekit-web3auth https://github.com/CloudNativeEntrepreneur/sveltekit-web3auth-template If you're not ready for the web3 auth world yet, you can also use , which comes preconfigured to connect to your local dev cluster, and a Keycloak instance that's set up within it. Seeing as how both projects issue JWTs, the goal is for the auth system to be interchangeable - use web3auth or classic OIDC - upstream usage of the tokens are the same. https://github.com/CloudNativeEntrepreneur/sveltekit-oidc Now go and make some hybrid dApps with autogenerated GraphQL APIs and robust RBAC and permissions and subscriptions and authenticated SSR pages and silent refresh loops and rotating refresh tokens and stuff! Conclusion In conclusion, no, JWTs and login with Ethereum/metamask are not mutually exclusive. In fact, if you like developer productivity and integrating with existing tools, I think you’ll do quite well using JWTs AND web3auth. Cheers! I’m available for consulting! If you’re interested in my help on a project you’re working on, send me a message on Twitter!

HELP! There’s a JWT in my Metaverse!

¡AYUDA! ¡Hay un JWT en mi metaverso!

AIDER! Il y a un JWT dans mon Metaverse !

मदद! मेरे मेटावर्स में एक JWT है!

ヘルプ！メタバースに JWT があります。

AJUDA! Há um JWT no meu Metaverso!

CỨU GIÚP! Có một JWT trong Metaverse của tôi!

帮助！我的元宇宙中有一个 JWT！

The time has come to build the next era of technology, to build the community-owned web, to build a decentralized future. It’s time to shift lanes, to not only experience the future but to build it. It’s time for Web3. Polygon presents Road to Web3 - a global hackathon in partnership with EthGlobal from Feb 3 - 9. Build your ideas and stand a chance to win prizes worth ! Road to Web3 is your chance to onboard yourself to Web3 and to shift gears from the Web2 world. 250,000 USD Why Polygon? is the leading platform for Ethereum scaling and infrastructure development. Its growing suite of products offers developers easy access to all major scaling and infrastructure solutions: L2 solutions (ZK Rollups and Optimistic Rollups), sidechains, hybrid solutions, stand-alone and enterprise chains, data availability solutions, and more. Polygon’s scaling solutions have seen widespread adoption with 7000+ applications hosted, 1B+ total transactions processed, ~100M+ unique user addresses, and $5B+ in assets secured. Polygon Bringing you the opportunity to build the decentralized future of tomorrow Take your Web3 experience to new heights and build your first project interacting with decentralized games, DeFi, NFTs, or take something you already love in Web2 and decentralize it! The 96-hour hackathon will also feature multiple talks and workshops for which we've gathered the best speakers, mentors, and thinkers such as , , , Patrick Collins, , and many more distinguished personalities in the space to help you learn and build with over 1000s of new friends around the world. ** Matthew Ball Ryan Wyatt Justin Kan Austin Griffith We’ve partnered with some of the most well-known protocols in the industry such as Web3Auth, Covalent, Uniswap Grants Program, Moralis, Chainlink, Superfluid, and The Graph to give you ample tools and resources to build any dApp you could possibly dream of and win additional prizes! Hackathon Timeline: Registrations Open - NOW! Registrations Close - 02 Feb 2022 Hackathon Begins - 03 Feb 2022 Project Submission Deadline - 07 Feb 2022 Finale - 09 Feb 2022 How to Participate? Apply via EthGlobal . You will receive further details about the hackathon once you finish the application process here Join the to stay up to date on the latest hackathon news and receive on-demand assistance. Discord server You can form your team (up to 5 members) or go solo. FAQ: Does Road to Web3 cost money? Road to Web3 is 100% free for hackers. All that we ask of you is that you focus on building your project, check-in with us on your progress regularly, and participate in the community we build around this hackathon. What is the stake? We require hackers to "stake" a little bit of money to lock in their position at the event. This stake serves as an extra incentive to build and it is returned after you have completed your project. There are many reasons why someone may have trouble staking, please reach out to us directly if you do.** How many people can be on a team? You can form teams of up to 5 people. There are no restrictions for team members, so you can team up with hackers of any country or experience level!** Is there a Code of Conduct? Yes! For years, EthGlobal’s core ethos has been to make it easy for anyone to dream big. To that end, we've developed a __ __All attendees must agree to and abide by the Code of Conduct at all times.** Code of Conduct. I'm new to Polygon and/or Ethereum. Can I participate? Absolutely! This event is specifically for you!** It doesn’t matter that you’re a beginner, everyone needs to start somewhere, and Road To Web3 is the perfect platform to begin your dApp building journey!  This one is for the changemakers, the doers, the builders. Someone has to build the next version of the internet, and that someone could be you. What are you waiting for? Registrations are open until February 2nd - Register NOW!

Introducing the Road to Web3 Hackathon Powered by Polygon

WEB3AUTH

web3auth.io

-- employees

Since n.d.

COMPANY RANKING

WEB3AUTH

EVERGREEN INDEX #11231

Representing this company? Click here to claim and customize this page!

Web3Auth WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

WEB3AUTH

web3auth.io

-- employees

Since n.d.

COMPANY RANKING

WEB3AUTH

EVERGREEN INDEX #11231

RELATED COMPANIESRANK

STORIES ABOUT WEB3AUTH

Representing this company? Click here to claim and customize this page!

Web3Auth WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!