Prysm is a Web3 financial platform for communities

Prysm

prysm

Prysmatic Labs is building out the first sharding implementation for the Geth (go-ethereum) client, allowing the Ethereum network to process transactions at over 10x — 100x of its current speed! In this video we chat with Raul Jordan, who is the co-lead at Prysmatic Labs. Video of the interview : Prysmatic Labs Website : Prysmatic Labs Github : Prysmatic Labs Chat (Gitter) : Links mentioned in this episode: https://prysmaticlabs.com/ https://github.com/prysmaticlabs/geth-sharding https://gitter.im/prysmaticlabs/geth-sharding?source=orgpage Things discussed in this episode: Background [ 0:47–2:01 ] Prysmatic Labs Overview [ 2:02–5:48 ] Sharding Overview [ 5:49–12:09 ] Sharding In-Depth [ 12:10–22:54 ] Prysmatic Sharding approach [ 22:55–24:41 ] Other Sharding Approaches [ 24:42 -31:16 ] Research Funding Space [ 31:17–34:02 ] Scalability Space [ 33:03–37:59 ] How To Get Involved? [ 38:00–40:13 ]

Ethereum Sharding Implementation — Prysmatic Labs

FACT SHEET: Biden-⁠Harris Administration High-Speed Internet Investments Spur Made-in-America Manufacturing Boom Today in Wisconsin, Vice President Kamala Harris will visit Nokia and Sanmina Corporation in Pleasant Prairie, Kenosha County, Wisconsin to highlight the Biden-Harris Administration’s efforts to invest in high-speed internet, boost domestic manufacturing, and create good jobs. Vice President Harris’ visit coincides with Nokia announcing the manufacturing of broadband network electronics products for the BEAD program in the U.S. that will add up to 200 new jobs at Sanmina Corporation’s state-of-the-art manufacturing facility in Pleasant Prairie, Kenosha County, Wisconsin. This event makes Nokia the first telecom company to announce the manufacturing of broadband electronics products in the United States, which will be ready in 2024. The Vice President will be joined by Commerce Secretary Gina Raimondo and Senator Tammy Baldwin. The announcement is the latest in a string of domestic manufacturing announcements that have been spurred by the Biden-Harris Administration’s high-speed internet investments and Made-in-America policies, part of the President’s Investing in America agenda and a clear sign that Bidenomics is working. Across the high-speed internet industry, most electronics products are not currently manufactured in the U.S., but Buy America provisions in the Bipartisan Infrastructure Law are driving the onshoring of new manufacturing, particularly ahead of implementation of the $42.45 billion Broadband Equity, Access and Deployment (BEAD) program. Just as Franklin Delano Roosevelt’s Rural Electrification Act brought electricity to nearly every home and farm in America, President Biden and Vice President Harris are delivering on their historic commitment to connect everyone in America to affordable, reliable high-speed internet by the end of the decade. The Biden-Harris Administration’s historic Internet For All initiative is investing $90 billion to bring affordable, reliable high-speed internet service to every community in America is creating good-paying manufacturing jobs and revitalizing the domestic broadband manufacturing industry. Other recent private sector domestic manufacturing announcements include: Corning, a producer of optical fiber and cable, celebrated the expansion of its U.S. manufacturing capacity with the opening of a new manufacturing campus near Hickory, North Carolina.  The more than $500 million investment to build fiber in the U.S. adds hundreds of manufacturing jobs to Corning’s more than 5,000 employees in the state. CommScope**,** a provider of broadband network equipment, recently announced a $60 million investment towards expanding its U.S. fiber optic cable manufacturing at its facility in Catawba, North Carolina. This investment will create more than 250 new jobs over the next five years, and create a fiber optic cable, “HeliARC” which is specifically designed for rural fiber network architecture. Prysmian, a manufacturer of optical fiber and fiber optic cable, announced a $30 million investment to convert its Jackson, Tennessee, copper cable facility into a state-of-the-art fiber optic cable manufacturing plant. As part of this plant retrofitting, Prysmian transitioned their workforce, retraining and retaining nearly 90% of employees. Prysmian has made a significant effort to hire and train female manufacturing workers, who make up 42% of plant employees compared to an industry average of about 25%. Buy Americarequirements are key to ensuring we maximize the economic potential of the Internet for All initiative. Manufacturing the iron, steel, fiber, and construction materials needed to deliver affordable, reliable high-speed internet service to millions of Americans is an opportunity to create jobs right here at home. Funds for the BEAD program will be used to purchase items manufactured in the U.S., such as iron, steel, and fiber. Additional specific rules for spending BEAD program funds are forthcoming. As President Biden said in his State of the Union address, “We’re making sure that every community — every community in America has access to affordable, high-speed Internet… I’m also announcing new standards to require all construction materials used in federal infrastructure projects to be made in America. Made in America. I mean it. Lumber, glass, drywall, fiber-optic cable.” Today’s announcement is part of President Biden’s Investing in America Agenda, which includes the historic investments from the Bipartisan Infrastructure Law, Inflation Reduction Act, the CHIPS and Science Act, and the American Rescue Plan. Together, these investments are unleashing a manufacturing boom, helping rebuild our infrastructure and bring back supply chains, lowering costs for hardworking families, and creating jobs that don’t require a four-year degree across the country. The private sector has already invested more than $500 billion in new manufacturing here in America, including for semiconductors, electric batteries, EV charging, rail manufacturing, water parts, and more. This content was published on August 3, 2023, on It has been republished on HackerNoon in line with the provisions of whitehouse.gov. Creative Commons 3.0.

Biden-Harris Administration Boosts Domestic Manufacturing with High-Speed Internet Investments

বিডেন-হ্যারিস প্রশাসন উচ্চ-গতির ইন্টারনেট বিনিয়োগের সাথে দেশীয় উত্পাদনকে বাড়িয়ে তোলে

Die Biden-Harris-Administration kurbelt die inländische Produktion durch Investitionen in Hochgeschwindigkeitsinternet an

La administración Biden-Harris impulsa la fabricación nacional con inversiones en Internet de alta velocidad

L’administration Biden-Harris stimule la fabrication nationale grâce à des investissements dans l’Internet haut débit

बिडेन-हैरिस प्रशासन ने हाई-स्पीड इंटरनेट निवेश के साथ घरेलू विनिर्माण को बढ़ावा दिया

バイデン・ハリス政権、高速インターネット投資で国内製造業を後押し

바이든-해리스 행정부, 고속 인터넷 투자로 국내 제조업 활성화

Administração Biden-Harris impulsiona a produção nacional com investimentos em Internet de alta velocidade

Администрация Байдена-Харриса стимулирует отечественное производство за счет инвестиций в высокоскоростной Интернет

Biden-Harris Yönetimi Yüksek Hızlı İnternet Yatırımlarıyla Yerli Üretimi Artırıyor

Chính quyền Biden-Harris tăng cường sản xuất trong nước bằng đầu tư vào Internet tốc độ cao

拜登-哈里斯政府通过高速互联网投资促进国内制造业

Ethereum is a digital world where money works in new ways, and it's super smart. But how does it make sure everything is fair and nobody tricks the system? Well, imagine Ethereum as a team of superhero computers. They all work together to check that everything is okay and no one is playing tricks. This blog will show you how these computer superheroes team up to keep your data safe and make sure everything is awesome in Ethereum land. Let's jump in and find out! What are Nodes and Clients? Ethereum nodes are like club members in a virtual space. They're individual computers connected to the network, cooperating to monitor transactions, contracts, and blockchain events. Nodes hold a complete blockchain copy, sync with others, and ensure accurate data. They validate transactions, uphold network integrity, and sustain Ethereum's smooth operation. The Ethereum network is structured into two distinct parts: the execution layer and the consensus layer. These two layers are managed by separate client software. In the discussion below, we'll use the terms "execution client" and "consensus client" to refer to these software components. Execution Client: These clients execute the smart contracts and transactions on the Ethereum network. They validate and process the code contained within transactions to update the state of the blockchain. Examples: Geth, Nethermind, Besu and Erigon. Consensus Client: These clients are responsible for participating in the consensus process to agree on the next valid block in the blockchain. They follow the Ethereum protocol rules to validate transactions, propose blocks, and achieve agreement with other clients. Examples: Lighthouse, Lodestar, Nimbus, Prysm and Teku. When the Merge happens, Ethereum shifts to a different way of confirming transactions called proof-of-stake. The execution and consensus clients team up to make sure Ethereum's status is correct. The execution client handles transactions and smart contracts, while the consensus client makes sure everything is agreed upon. Together, they keep Ethereum running smoothly and securely After the Merge, you can't use only the execution client. Both execution and consensus clients must run together for access to Ethereum. It's like needing two friends to open a special club – they both have to be there for you to join the fun. Why is it important to have Client Diversity? Having different software options (clients) following the same rules in networks like Ethereum is called client diversity. This variety, like Geth, OpenEthereum, and Besu for Ethereum, makes the network stronger and safer. If one client has a problem, the others can keep the network running smoothly. This diversity also encourages innovation, provides choices for users, and helps maintain a decentralized and strong network. What these implementations have in common is they all follow a single specification. Specifications dictate how the Ethereum network and blockchain functions. Types of Nodes : A full node is like having the whole book. It has a complete copy of the entire Ethereum history, including all transactions and smart contracts. It helps check and confirm new transactions and keeps the network secure. Full Node : A light node is like reading the summary. It doesn't store everything, but it can quickly check recent transactions and smart contracts by asking other nodes for information. It's useful if you want to use Ethereum but don't need all the details. Light Node : An archive node is like having every old newspaper. It stores the complete history, just like a full node, but also keeps old states of the Ethereum world. This can be useful for looking up past data, like checking the contents of an old smart contract. Archive Node Why should we run Ethereum nodes? Running an Ethereum node has many benefits. Firstly, you can double-check transactions for safety. Secondly, you control your access to Ethereum's info, keeping things private. Thirdly, you help make Ethereum stronger and more spread out by supporting the network with your node. Plus, you can talk directly to smart contracts and learn how Ethereum really works. Also, you don't have to just trust the network – you can check things yourself using your own client. What does the Execution Client Do? Execution clients verify incoming transactions to ensure they're properly formatted and valid. They check details like the sender's signature and whether the sender has enough funds to carry out the transaction. Transaction Verification: Clients calculate the amount of gas required for transaction execution. Gas acts as a fee and covers the computational resources needed to process the transaction. Gas Calculation: Execution clients have an Ethereum Virtual Machine (EVM) that interprets and executes the bytecode contained within smart contracts and transactions. The EVM is like a computer processor dedicated to running Ethereum code. Ethereum Virtual Machine (EVM): Clients execute the code of smart contracts on the EVM. This involves following the instructions provided by the contract's code, updating data and balances, and interacting with other contracts if necessary. Smart Contract Execution: Execution clients modify the state of the Ethereum blockchain based on the outcomes of transactions and smart contract execution. This includes updating account balances, contract storage, and other relevant data. State Changes: Execution clients facilitate the emission of events from smart contracts. These events are like notifications that certain actions have occurred, and they can be monitored by applications and users. Event Emission: If a transaction or contract execution encounters errors or exceptions, execution clients manage these situations and ensure that the blockchain remains consistent. Error Handling: Clients track the gas used during transaction and contract execution. If a transaction runs out of gas, it is reverted, and any changes to the state are undone. Gas Management: Execution clients can interact with external data sources through various mechanisms, enabling smart contracts to access information beyond the blockchain. Interactions with External Data: What does the Consensus Client Do? When it's time to add new transactions to the blockchain, the consensus client helps some nodes propose blocks. These blocks contain a list of transactions that need to be added. Block Proposals: Other nodes in the network, including the consensus client itself, check the proposed blocks to make sure they're correct and follow the rules. It's like having a bunch of people review a suggestion before deciding if it's good. Checking and Voting: Nodes discuss and agree on which block should be added next. The consensus client helps everyone come to an agreement, so they all choose the same block. Agreement Process: Once most of the nodes agree on a block, the consensus client makes that block official. It's like putting a stamp on a decision to show that it's the right one. Final Decision: The consensus client prevents confusion by making sure everyone in the network is on the same page. It stops any disagreements and makes sure the blockchain's history is clear and agreed upon by everyone. Avoiding Confusion: The consensus client also helps prevent any bad actors from trying to cheat or disrupt the network. It makes sure that everyone follows the rules, and if someone tries to break the rules, they'll be caught. Security Measures: As new blocks get added, the consensus client helps make the blockchain longer and keeps track of the correct order of events. New Chain Parts: Validators People who operate Ethereum's computer system can become validators by depositing 32 units of Ethereum's currency (ETH) into a special account. Once they become validators, they receive a helper program that comes with Ethereum's main computer program. This helper program assists with important tasks like confirming certain actions (attestations) and suggesting new actions to add to Ethereum's records (block proposals). Validators have the opportunity to earn more Ethereum as a reward for doing well and following the rules, but they could also lose some ETH if they don't play fair. Being a validator also makes them eligible to propose new actions for Ethereum Execution Client Consensus Client Validator Handles transaction processing and smart contract execution. Helps nodes agree on blockchain state and block validity. Proposes new blocks, confirms transactions, and earns rewards. Shares transaction information across the network. Shares block and confirmation info across the network. Participates in block proposal and attestation communication. Manages the state of Ethereum and updates balances and data. Keeps track of the latest valid blocks and chain state. Helps maintain the Beacon Chain state and validator participation. Provides JSON-RPC API for external interaction. Facilitates communication through network protocols. Performs actions based on Ethereum rules and protocols. Ensures transactions are executed properly. Aids in reaching consensus on the blockchain state. Proposes new blocks and validates network actions. Not directly involved in rewards/penalties. Not directly involved in rewards/penalties. Earns rewards for good behavior, can be penalized for bad behavior. How do Light Client Work? When Ethereum started using a different way for computers to agree on things (called proof-of-stake), they made some changes to help smaller computers work better. They created new tools for what we call "light clients." Here's how it works: Imagine there's a group of important people (validators) who sign their names on a paper that says everything is okay. Every 1.1 days, a random group of 512 of these important people forms a team (sync committee). They sign their names on a paper that talks about recent things happening. This paper also says who from the team signed and who didn't. The paper also gives a list of names of the people who will sign the next paper. Now, if you're a smaller computer, you don't need to get the big paper with all the details. You just need the part with the signatures and the list of names. This helps you know that everything is good without getting all the extra stuff. On another part of the computer work, there isn't one exact way to make a small computer understand everything. Sometimes, a small computer can be like a "light" version of a big one. It has some abilities but doesn't do everything. It can quickly check if everything is okay by asking a bigger computer. Or, it can be even simpler and mostly ask for help from a special service to understand things. In the end, these changes make it easier for smaller computers to stay updated with the latest Ethereum news without having to do all the heavy work. They get the important parts without downloading everything. Why are Light Client Important? Light clients are important because they let users check information they receive instead of blindly believing it. They use only a small amount of computer power, memory, and storage, which is much less than a full computer. Light clients are like a "lite" version of the full thing, and they can run on mobile phones, apps, or even in web browsers. They help people access Ethereum without needing to fully trust someone else to give them the right info. Here's an example to make it simple: Imagine you want to see how much money you have in your account. You ask an Ethereum computer for this info. It checks its own records and tells you. But if you can't check it yourself and have to ask someone else, you have to trust them. Light clients fix this. You still ask someone else, but they give you a proof along with the info. Your light client checks the proof and the info from the main Ethereum group. This way, Ethereum itself makes sure you're getting the right info, not just a random person. Why Execution Layer is Overwhelmingly Dominated by Geth? The execution layer of the Ethereum network, responsible for transaction processing, smart contract execution, and maintaining the blockchain's state, is predominantly and significantly influenced by the widely used Go Ethereum (Geth) client. Geth plays a pivotal role in ensuring accurate and secure execution of transactions and smart contracts, contributing to the network's overall functionality. Its extensive adoption underscores its importance in supporting Ethereum's core operations and interactions, despite the value of maintaining a diverse client ecosystem for enhanced resilience and innovation. Go Ethereum (Geth) offers as both an Ethereum client and a consensus client: As an Ethereum Client: Geth processes and validates transactions, ensuring accurate execution of actions on the Ethereum blockchain. Transaction Processing: It runs the Ethereum Virtual Machine (EVM), enabling the execution of smart contracts and decentralized applications. Smart Contract Execution: Geth manages the state of the Ethereum blockchain, keeping track of account balances, contract storage, and data changes. State Management: Geth communicates with other nodes through Ethereum's peer-to-peer protocol, sharing information about transactions, blocks, and network activities. Network Communication: Geth exposes a JSON-RPC API that allows developers to interact programmatically with the Ethereum network, facilitating various functionalities and data retrieval. JSON-RPC API: It helps new nodes synchronize with the Ethereum network, ensuring they have the most up-to-date blockchain data. Syncing: Geth incorporates changes proposed by EIPs, contributing to the evolution and improvement of Ethereum's protocol. Ethereum Improvement Proposals (EIPs): Geth supports the creation of private Ethereum networks for development and testing purposes. Private Networks: As a Consensus Client: Geth participates in validating and agreeing upon new blocks through the PoW consensus mechanism, ensuring the security and integrity of the blockchain. Proof of Work (PoW) Validation: In Ethereum 2.0's PoS mechanism, Geth interacts with the Beacon Chain, contributing to consensus activities like attestation and block proposal. Proof of Stake (PoS) Beacon Chain Interaction: Geth verifies the validity of proposed blocks, ensuring they adhere to the consensus rules and Ethereum protocol. Block Verification: It assists in resolving forks by selecting the longest and most valid chain, maintaining network stability. Fork Resolution: Geth actively communicates with other nodes, participating in the dissemination of new blocks and transactions, and contributing to the overall consensus process. Participation in Network Activities: This blog explored how Ethereum's network works, including how transactions and contracts are managed, and how everyone agrees on what's valid. It highlighted the key role of Go Ethereum (Geth) in making all of this happen smoothly. Geth helps process transactions, ensures agreements, and keeps things secure. It's like the glue that holds Ethereum together, and its open teamwork helps keep everything running well.

How Ethereum Clients Work Together for Security and Consensus

Are you ready to ride the Ethereum 2.0 wave and start earning validator rewards? If so, you've come to the right place. In a previous article, I discussed how we can set up the Ethereum 1.0 node, check it out . We'll walk you through the process of setting up an Ethereum 2.0 node and validator account using Docker Swarm. By the end of this guide, you'll be a pro at contributing to the Ethereum 2.0 network and earning rewards in no time. So, grab your favorite drink, buckle up, and let's get started! here 😎 🚀 ⚙️️Getting Started Before we dive into the setup, make sure you've got the following tools and resources ready: Docker and Docker Swarm installed on your computer. If you need help, follow the official installation guide: https://docs.docker.com/get-docker/ At least 32 ETH to stake for your validator account. 🐳 Step 2: Creating the Docker Compose File Now that Docker is ready, let's create the docker-compose.yml file that will define our Ethereum 2.0 node and validator setup. Choose or create a directory on your computer where you'd like to store the project files. This could be any location that's easy for you to access. For example, you can create a new directory called in your home folder. Open the terminal and run: eth2-node mkdir ~/eth2-node cd ~/eth2-node Next, create a new file named docker-compose.yml using a text editor of your choice. For instance, on the terminal, you can use the nano text editor: nano docker-compose.yml Once the file is open in your text editor, copy and paste the following contents: docker-compose.yml version: '3.9' services: beacon-node: image: gcr.io/prysmaticlabs/prysm/beacon-chain:latest volumes: - ./data:/data command: --datadir=/data --http-web3provider=<YOUR_ETH1_NODE_URL> networks: - eth2 validator: image: gcr.io/prysmaticlabs/prysm/validator:latest depends_on: - beacon-node volumes: - ./validator:/validator command: --wallet-dir=/validator --beacon-rpc-provider=beacon-node:4000 networks: - eth2 networks: eth2: Make sure to replace with your Ethereum 1.0 node URL. <YOUR_ETH1_NODE_URL> 🏦 Step 3: Creating a Validator Account Before we deploy our setup, we need to create a validator account. To do this, download and install the Eth2.0 Deposit CLI tool from . https://github.com/ethereum/eth2.0-deposit-cli Follow the instructions to generate a validator key pair and deposit data file. Store the keys in the directory, which you'll need to create within your eth2-node project folder: ./validator mkdir ~/eth2-node/validator 💰Step 4: Staking 32 ETH Now it's time to stake your 32 ETH! Head over to the Ethereum Launchpad at . Follow the steps on the website and deposit 32 ETH using the deposit data file generated in Step 3. Make sure to save the transaction hash for future reference. https://launchpad.ethereum.org/ 🚢Step 5: Deploying the Setup with Docker Swarm With your deposit sent, it's time to deploy your Ethereum 2.0 node and validator setup using Docker Swarm. Run the following command in your terminal: docker stack deploy -c docker-compose.yml eth 2 This command will create the beacon node and validator containers. 📝Step 6: Checking the Status of Your Containers To check the status of your containers, you can use the command, which will list all your running containers, including your Ethereum 2.0 node and validator. docker container ls 🌐Step 7: Syncing the Beacon Node It might take some time for the beacon node to sync with the Ethereum 2.0 network. You can monitor the progress using the following command: docker logs -f < beacon_node_container_id > Once your beacon node is fully synced, your validator will begin validating blocks and earning rewards! 👁️‍🗨️Step 8: Monitoring Your Validator's Performance To keep tabs on your validator's performance, you can use Beaconcha.in ( ) or Etherscan ( ). Enter your validator's public key on either website to track its status, rewards, and penalties. https://beaconcha.in https://etherscan.io 🔐Security Best Practices As a validator, it's crucial to keep your validator keys safe. If you lose these keys, you won't be able to withdraw your staked ETH and rewards. Additionally, avoid running multiple instances of the same validator, as this could result in slashing penalties. And... that's a wrap! 🥳Congratulations! You've successfully set up an Ethereum 2.0 node and validator account using Docker Swarm. You're now actively contributing to the network's security and earning rewards in the process. The Ethereum 2.0 ecosystem is continually growing, so stay up-to-date with the latest developments, tools, and applications. Connect with the Ethereum 2.0 community on forums, Discord, and GitHub to exchange ideas and knowledge. Happy staking!

How to Set Up an Ethereum 2.0 Node & Validator Using Docker Swarm: A Step-by-Step Guide

ডকার সোয়ার্ম ব্যবহার করে কীভাবে একটি ইথেরিয়াম 2.0 নোড এবং যাচাইকারী সেট আপ করবেন: একটি ধাপে ধাপে নির্দেশিকা

So richten Sie einen Ethereum 2.0-Knoten und -Validator mit Docker Swarm ein: Eine Schritt-für-Schritt-Anleitung

Cómo configurar un nodo y un validador de Ethereum 2.0 mediante Docker Swarm: una guía paso a paso

Comment configurer un nœud et un validateur Ethereum 2.0 à l'aide de Docker Swarm : un guide étape par étape

डॉकर झुंड का उपयोग करके एथेरियम 2.0 नोड और सत्यापनकर्ता कैसे सेट करें: एक चरण-दर-चरण मार्गदर्शिका

Docker Swarm を使用して Ethereum 2.0 ノードとバリデーターをセットアップする方法: ステップバイステップ ガイド

Docker Swarm을 사용하여 Ethereum 2.0 노드 및 유효성 검사기를 설정하는 방법: 단계별 가이드

Como configurar um nó e validador Ethereum 2.0 usando o Docker Swarm: um guia passo a passo

Docker Swarm Kullanarak Ethereum 2.0 Düğümü ve Doğrulayıcı Nasıl Kurulur: Adım Adım Kılavuz

Cách thiết lập Nút Ethereum 2.0 & Trình xác thực bằng Docker Swarm: Hướng dẫn từng bước

如何使用 Docker Swarm 设置以太坊 2.0 节点和验证器：分步指南

Introduction Ethereum’s transition to Proof-of-Stake (dubbed The Merge) is easily the most significant and anticipated improvement of the blockchain network since its genesis in 2015. The Merge has been in the works for as long as Ethereum has been live, and it will occur at Total Terminal Difficulty (TTD) 58750000000000000000000, or somewhere between . September 13th and 15th The Ethereum community, whether they are developers, stakers, or end-users, obviously have many questions related to preparing themselves for the Merge, depending on how they interact or build on top of the network. One of the largest changes to the blockchain is the replacement of Proof-of-Work miners with Proof-of-Stake validators. There is a hope that one of the most welcome changes as a result of this is the rise of solo stakers that strengthen the robustness, security, and decentralization of Ethereum. In this article, we will explore what solo staking is, what you need to be aware of if you’re already a solo staker post Merge, and how you can prepare ahead of the Merge. A Primer on Proof-of-Stake Proof-of-Work is a consensus mechanism used by blockchains like Bitcoin in order to achieve agreement across the network. In this protocol, miners compete with one another to solve cryptographic puzzles and earn the right to create a block in exchange for rewards. This requires a lot of energy and causes miners to spend  huge amounts on electricity to have the capital required to secure the network and an incentive to act honestly. On the other hand, a blockchain network using the Proof-of-Stake consensus protocol replaces miners with validators who deposit a certain amount of money with the network (32 ETH in Ethereum’s case) in exchange for the ability to mine new blocks and verify existing blocks. The network chooses a validator at random whenever a new block needs to be created, and other validators verify that the created block is legitimate. If a validator is honest and functions as desired, it receives rewards. However, if a validator acts dishonestly or refuses to perform desired functions, they lose part or all of the tokens that it has staked. By replacing electricity with staked cryptocurrency as the primary method of securing the protocol and keeping participants honest, Proof-of-Stake can reduce energy consumption of the network . It also makes participation more democratic by allowing people without expensive hardware and mining farms to take part in maintaining the network and earning rewards. by more than 99% What is Solo Staking? Solo staking is the process of participating directly in the network consensus (as an individual) by running an Ethereum node and activating a validator by depositing exactly 32 ETH. Why would you solo stake? Solo stakers are able to receive rewards—up to 15% annual percent yield (APY) on staked ETH—directly from the protocol by keeping their validator functional and online. They operate in a completely trustless environment, having total control over their keys, software clients, and hardware. Since solo staking is technically done by individuals, it is considered to be an attractive form of staking as it increases the decentralization and security of the entire network, while being autonomous. An alternative to solo staking would be to participate in a staking pool service such as or . However, with this approach, you would not have complete control over the node’s network activities. If the validator is not performing as it should, you risk losing your staked ETH. Additionally, any rewards received would be a fraction of what you could earn as a solo staker. With Rocket Pool, you can run one of their nodes, but you must use their software, and again, the rewards will not be as high as running your own node. Rocket Pool Lido How to Solo Stake Using Infura In order to solo stake, you will need the following: To run a validator, you need to deposit 32 ETH to a designated contract. As it stands, you cannot remove your staked ETH. This will only be possible after the Shanghai upgrade which may be six to 12 months after the Merge. Therefore, be mentally prepared to lock up your ETH for some time. At least 32 ETH Although it is possible to run a validator from your main computer, it is strongly advised that you assign a dedicated machine for the purpose. The hardware should have at least 4 - 8 GB RAM, at least 1 TB SSD, and access to an internet connection faster than 10 Mbps. Refer to Ethereum’s page for more details and other by ConsenSys. Dedicated hardware run a node hardware recommendations There are two pieces of software you will require for your Infura node to act as a validator post-Merge: Software clients Execution layer client - (Formerly Eth1 clients) Responsible for transaction bundling, execution, and chain state management. Examples include: Geth (Go Ethereum), Nethermind, Erigon, and Hyperledger Besu. Consensus layer client - Responsible for PoS consensus, block seal validity, and fork choice rule. Examples include: Prysm, Lighthouse, Nimbus, Lodestar, and Teku. Here is an that outlines the steps on how to set up both. Installation may require a certain level of comfort with computers and the command line. Note that failure to install these clients ahead of the Merge will result in your node being seen as “offline” after the Merge until both layers are synced and authenticated. Infura workshop You’ll be required to maintain your hardware and make sure it stays online and connected to the network. You’ll also have to make sure that your software clients are upgraded and updated regularly. Also, as mentioned earlier, if your validator node is not performing properly, you risk losing some, or all of your 32 staked ETH. Fortunately, the Ethereum Foundation has released a that walks you through all the steps to set up and run a validator node in great detail, as well as . This includes highlighting risks, choosing hardware and software clients, generating and securing keys, and becoming a full fledged solo validator on the Ethereum PoS network. It’s also important to note that only 32 ETH per validator node will be counted towards rewards. Anything over 32 ETH does not count unless you spin up another node. Launchpad ConsenSys Considerations for Solo Stakers As stated above, one of the most important steps that a solo staker will need to take is the installation and configuration of software clients. The Ethereum Foundation states on their webpage on preparing for the Merge that a Staking Validator (another term for Solo Staker) will need to: Run both a consensus layer client and an execution layer client. Authenticate both execution layer and consensus layer clients with a shared JSON Web Token (JWT) secret so they can securely communicate. . Not completing the first two items above will result in your node being seen as "offline" after the Merge until both layers are synced and authenticated Set a fee recipient address to receive your earned transaction fee tips/MEV. Not setting a fee recipient will still allow your validator to behave as usual, but you will miss out on unburnt fee tips and any MEV you would have otherwise earned in blocks your validator proposes. Ideally, you should choose clients that have their essential code open sourced, audited, and battle-tested. Infura offers the best in class execution layer and consensus layer clients in the form of and ConsenSys respectively. These clients have been developed in collaboration with the broader open source community and ensure that your validator node doesn’t go offline during the Merge. Hyperledger Besu Teku To optimize the value your nodes can provide, be sure to learn about (MEV). Software produced by Flashbots, called , can help maximize value for each proposed block by allowing validators to purchase blocks with transaction orders already optimized. Since the software is compatible with all Ethereum consensus clients, mev-boost helps democratize access to MEV, while ensuring the most profitable blocks. maximal extractable value mev-boost To encourage adoption as well as educate stakers on its use, Infura also recently hosted a series of weekly featuring Michael Wuehler, a solo staker and co-founder of Infura. Finally, Infura has also released a series of articles highlighting one solo staker’s experience of becoming a validator on Ethereum. You can review those articles here: Merge workshops What You Need to Know to Prepare for the Merge: Infura Developers Edition My Journey to Becoming a Validator on Ethereum 2.0, Part 5 How to Monitor Your Eth2 Validator and Analyze Your P&L How to Safely Migrate Your Ethereum 2.0 Validator Client Preparing for the Merge One of the reasons the Merge has been in the works for so long is to ensure that the transition is as seamless as possible for all the parties involved. That said, here are a few things you could do as a solo staker to be well prepared. Gain a holistic understanding of what the Merge is, why it is being done, and why it is important (not just for Ethereum but for the blockchain ecosystem as a whole). is’ is an excellent place to start. The Consensys Merge hub Try and stay as active as possible with the overarching Ethereum ecosystem. We recommend you do the following: Attend community events or join communities, such as ETHStaker Read the official Merge docs Participate in testing and verification activities Acquire more ETH, if required Follow the news—Ben Edgington’s is an excellent source What’s New In Eth2 Accumulate Merge resources Stay patient Gain an understanding of the various components you need to have in order to solo stake, including the Authentication Engine API, the consensus client, and the execution client. and the are excellent places to start. The Merge readiness checklist official Ethereum solo staking documentation Be aware that the ETH you deposit in order to participate will be locked for the near future. You will not be able to withdraw your funds until the planned Shanghai upgrade so be sure to budget your finances accordingly. Be wary of scams that may pop up in the form of forked Ethereum PoW chains. Before you think about trying to make a quick buck dumping your PoW coins, check out this . Reddit post highlighting potential risks Once you feel like you’re finally ready to stake your ETH, follow the instructions on to become an active validator on the PoS network. Ethereum’s Launchpad Conclusion Solo staking is one of the most exciting activities that will come to life post Merge. Allowing individuals to directly participate in network consensus and earn rewards goes a long way towards achieving Ethereum’s goals of near perfect security and decentralization. The Ethereum Foundation and Infura have taken critical efforts to make the process of solo staking as seamless and democratic as possible. However, that doesn’t mean you do not need to take the steps highlighted above to prepare yourself. We hope you are as excited as us about the future of blockchain and the internet! Also Published Here Disclaimer: Nothing in this article constitutes professional investment advice. Please do your own thorough research before making any investment decisions.

Solo Staking on Ethereum and Earning Rewards Using Infura After The Merge

The launch date for “the Merge” (merging the Beacon Chain with Ethereum Mainnet) is rapidly drawing close. Per the latest , the Beacon Chain has over 300,000 validators and more than 10 million ether (ETH) in validator stakes. stats Ethereum’s switch from a proof-of-work to a proof-of-stake consensus mechanism has several implications for its future. With the Beacon Chain as a consensus layer, Ethereum PoS promises better network security, energy efficiency, scalability, and decentralization. However, it also introduces new challenges that could threaten Ethereum’s functionality. One of those challenges is achieving ideal client diversity. In a decentralized network like Ethereum, diversity of client software is necessary for enhancing network security, functionality, and censorship resistance. However, current stats show that Ethereum's PoS consensus layer (the Beacon Chain) is lacking in the client diversity department. As we'll find out in this article, the centralization of software implementation has critical implications for the Ethereum ecosystem. ELI5: What Does Client Diversity Mean? Ethereum is a decentralized peer-to-peer network sustained by a globally distributed collection of nodes (i.e., computers). Each node runs a “client”—this is software that helps nodes to interact with the Ethereum blockchain. Without clients, nodes cannot broadcast and verify transactions, execute smart contracts, or reach consensus on the blockchain state. Clients are a critical part of Ethereum’s infrastructure, which is why its developers opted for a multi-client arrangement. As opposed to running a single client, nodes are incentivized to run different client implementations—the end goal being that no client should hold a supermajority. Client diversity simply means having a fair distribution of client software on network nodes. Ideally, no client should power more than 33% of nodes in a decentralized system like Ethereum. Or else, several bad things (which we explore later) can start to happen. Currently, Ethereum's Beacon Chain doesn't have an equitable spread of client software across nodes running the network. As the chart below shows, the majority client controls > 68% of validators, which can put the system at risk for different reasons. [ ] Image source Client diversity is a hotly debated topic in the Ethereum community. And that's due to its importance to Ethereum's performance, especially in the context of the Merge. The debate also exists because of . disagreements on how client diversity should be realized So, why exactly is client diversity so important? That's what we're about to find out. The Importance of Client Diversity As a distributed system, Ethereum relies on the network of peer-to-peer nodes to function optimally. In turn, those nodes rely on clients to help them contribute to the network. Any flaws or bugs in client software will affect a node's participation in the network. If the problem is constrained to one client, then the network can continue to function. Other nodes running alternative clients will manage the blockchain, while the affected nodes can switch to a non-affected client. The above scenario can only work if, and only if, a small number of nodes are using the affected client software. A case where the majority of nodes run the malicious software could create single points-of-failure and affect the network significantly. Here are some potential problems that could happen in this case: Restrictions on Transaction Finality Finality in blockchain lingo is a guarantee that transactions cannot be reversed, altered, or canceled. If a blockchain finalizes, committed blocks cannot be revoked. Finality is what gives Ethereum, and other blockchain networks, their "immutable" quality. Anyone can use Ethereum knowing transactions will be recorded permanently on the chain and cannot be tampered with. Typically, blockchain networks need the majority of nodes to reach consensus before achieving transaction finality. In the Beacon Chain, at least 2/3 of staked ETH is required to finalize the chain. Anything lower than that, and the chain cannot finalize—putting the system in jeopardy. So, how does this relate to flawed client software? Well, you have to consider what can cause a situation where nodes are unable to reach consensus. We could think of different reasons, but the most realistic one is simple: validating nodes are malfunctioning. If 1/3 of validators are inactive, then there wouldn't be a 2/3 supermajority required for Beacon Chain finality. To remedy the problem, the Beacon Chain activates the Inactivity Leak Mechanism. This mechanism is designed to gradually reduce the stakes of offline validators, allowing the remaining nodes to re-form a two-third majority. If all goes well, the remaining nodes can achieve consensus and keep the chain running. In this scenario, the heaviest losers are validators who have their ETH stakes slashed. Network Split The preceding section explored what could happen if a faulty client powers more than 1/3 of validating nodes. But, that’s only the beginning—worse things can happen, especially if > 1/2 of validators are running the bad client software. In this case, the Beacon Chain network can split into two separate chains. Both chains will be unable to finalize because half their validators are missing; hence, the Inactivity Leak mechanism will activate. Deposits belonging to affected validators will get destroyed over a while—three to four weeks, say—until they control less than 1/3 of staked ETH. The result is that the old and new chains will finalize independently, making it hard to merge them later. To merge both chains, the community would need to agree on the canonical chain—a process likely to be fraught with politics. The reason is simple: asking validators to join another chain would cause them to lose their entire stakes. A network split would force over half of the community to suffer huge economic losses. To avoid this fate, validators on the discarded chain may decide to continue running the forked chain, splitting the Ethereum community. This is reminiscent of the events surrounding the DAO hack of 2016 when a faction—disgruntled with the handling of the situation— and created Ethereum Classic. Not only would a split weaken Ethereum, but it could depreciate the price of ether on the market. forked the network To prevent a network split, developers would need to quickly patch the consensus bug each chain finalizes. Otherwise, it’d become difficult, if not impossible, to ever merge both chains into one canonical chain. before Reversing Transactions If a faulty client running > 1/2 of Beacon Chain validators is catastrophic, then a situation where > 2/3 of nodes use the same vulnerable software is Armageddon. A new chain comprising nodes with the affected client will split from the Beacon Chain and—because it has a 2/3 supermajority—finalize independently. At most, developers will have ~ 13 minutes to patch the software before the split chain achieves finality. This is assuming the developers are nice guys who genuinely love Ethereum. If the developers go rogue—or malicious actors infiltrate the organization—they can hijack the chain and do considerable damage. They could very well rewrite the entire blockchain history (and double-spend funds), censor transactions, or even reverse old transactions. Even if the bug were an honest mistake, the situation would still be less than ideal. Let’s look at some hypothetical scenarios in this case: Fix #1 One way to fix this problem is to have nodes accept the bug as the normal behavior of Ethereum. What that means is that unaffected nodes will reproduce the bug and try to join the other chain. Afterward, developer teams can coordinate on a fix, and validators can update their client software to reflect the change. But this isn’t an easy solution to implement. First, unaffected nodes will be punished for inactivity even if they acted honestly. Second, this fix only covers trivial errors; severe consensus bugs would make the corrupted chain incompatible with the rest of the network. This brings us to the second solution. Fix #2 Another option in this event would be to patch the vulnerable client. However, there’s no way validators running the once-faulty client can safely rejoin the canonical chain without getting penalized. Here’s why: Due to a large number of validators exiting their stakes on the compromised chain, the Inactivity Leak mechanism will activate. Which means affected validators can lose a lot of money, especially because exits can be painfully slow. Now, this is the point where I say, “but wait, there’s more!”. Let’s imagine the affected validators successfully exit the bad chain and attempt to rejoin the correct chain. Because they already attested to one chain, any attempt to attest to another chain would lead to a slashing of their ETH stakes. unfinalized In other words, we have a dilemma on our hands: If the affected validators voluntarily exit their stakes, they’ll likely get caught up in the inactivity-related slashing. If they try to join the ‘good’ chain immediately (when it hasn’t finalized), their stakes get slashed per protocol rules. In the end, no one benefits from having this problem happen. Which is why a client controlling more than 2/3 of validating nodes is cause for alarm. Can Ethereum Client Diversity Improve? By now, the importance of diversity to the health of the Ethereum network should be obvious—especially if we want to keep Ethereum decentralized. But, if the numbers are anything to go by, Ethereum’s Beacon Chain is yet to achieve a fair distribution of clients. The dominant client, Prysm, controls > 68% of nodes on the Beacon Chain, putting us firmly in Armageddon territory. It may seem alarmist to raise concerns over a single client having a supermajority, but these problems are from being hypothetical. In August 2020, Medalla (a Beacon Chain tesnet) suffered a major crash. The reason? Nodes running Prysm software malfunctioned due to a clock bug in the client. As a result, Prysm nodes went offline, leaving the chain unable to finalize. Developers finally fixed the problem hours later, but not before validators lost their stakes due to slashing. If the majority of nodes hadn’t been using the same software, then the problem would have been corrected easily. History also shows why client diversity is important. For example, in 2016, hackers by exploiting vulnerabilities in the Go Ethereum (Geth) client. The network survived because nodes could switch to the Parity client which was safe from the attack. targeted Ethereum with a distributed denial-of-service (DDoS) attack Client diversity is hard to achieve because nodes cannot be unilaterally forced to run a particular client. Moreover, dominant clients usually enjoy first-mover advantages and network effects, making them hard to displace. Nonetheless, there are various possible solutions for improving software diversity: Protocol Incentives Ethereum’s Casper PoS mechanism, which controls the Beacon Chain, is designed to discourage majority use of a particular client. It incentivizes client diversity through anti-correlation penalties and quadratic inactivity leak fees. Quadratic Inactivity Leak If you’ve read the article up until this point, you may be familiar with the quadratic inactivity leak. Typically, validators on the Beacon Chain can get penalized for dishonest activity or failing to perform their duties (e.g. going offline). Standard inactivity penalties are low (around 1 ETH) and validators will still have most of their stake intact. However, if > 1/3 of validators are inactive, things start to look different. The chain cannot finalize in this situation, which threatens —an indispensable quality for all distributed systems, not just blockchains. liveness In a quadratic leak scenario, inactivity fees will increase quadratically until offline validators have their stakes reduced to less than 1/3 of the network. The rationale is that, if anything knocks a large number of validators offline, the chain can still achieve finality. Remember that we need 2/3 of stakers to reach consensus for the Beacon Chain to finalize? The Inactivity Leak mechanism will ensure that offline nodes hold less than 1/3 of stakings, allowing remaining validators to create the required two-thirds supermajority. The implication is that if you run the dominant client, your node will likely go offline during the inactivity leak. This means you’ll lose ETH like crazy until the bug gets fixed and liveness is restored to the chain. Anti-Correlation Penalties In addition to encouraging software diversity, anti-correlation penalties are designed to prevent the possibility of malicious collusion. The quadratic inactivity leak is a type of anti-correlation penalty, although the punishments discussed in this section are heavier. The first anti-correlation penalty touches on validators producing bad attestations, i.e., validating malicious transactions. If a majority client experiences a bug that causes validators to give false attestations, they’ll lose 100% of their stakes. In other words, the more nodes that act maliciously, the higher the penalty. The second anti-correlation penalty touches on validators attesting to an invalid block. This is something we’ve explained earlier, but we’ll look at it again. If an invalid block is committed to the beacon chain, other nodes will reject it and form a new chain that doesn’t have the block in it. The only option for nodes on the valid chain is to switch to the correct chain; however, this attracts a penalty, as a significant percentage of ETH stakes get slashed. These incentives are put in place to promote a multi-client culture in Ethereum. As such, validators are encouraged to run minority clients. Running Minority Clients The more obvious step to achieving better client diversity is getting nodes to run different clients. By running different software, validators can ensure Ethereum remains robust, secure, and functional. Moreover, running a minority client is in your best interests as a validator—especially with anti-correlation penalties and inactivity leak fees. You won’t necessarily escape punishment by running a minority client, but the penalties will be lower. These are some minority consensus clients you can run: Lodestar Teku Nimbus Lighthouse We’ve focused squarely on consensus clients, i.e. Beacon Chain nodes, in this article. However, Ethereum Mainnet has a similar problem. Per stats, Go Ethereum (Geth) controls > 80% of nodes, with Nethermind, OpenEthereum, and Erigon trailing with low figures. [ ] Image source Since the execution layer is as important as the consensus layer, it needs client diversity as well. To solve the problem, nodes on Ethereum Mainnet can run the following execution clients: Hyperledger Besu Nethermind Erigon CoreGeth Final Thoughts Beyond the immediate security benefits, client diversity can create a richer Ethereum ecosystem. Each client works with different languages, design features, and architectures, inspiring greater innovation and exchange of ideas. As Ethereum undergoes the biggest change since its inception, it is important to encourage diversity across the network. Only then can it remain a robust and highly functional decentralized system. References Validated, staking on eth2: #1 - Incentives Ethereum Merge: Run the majority client at your own peril! Eth2book: The Incentive Layer Cover image courtesy of Getty Images Also published on Business Tech Guides

Ethereum's Client Diversity Problem

Special thanks to Kevin Owocki and Frank Chen for help and review. Initially published on Apr 30, 2020. Round 5 of Gitcoin Grants has just finished, with $250,000 of matching split between tech, media, and the new (non-Ethereum-centric) category of "public health". In general, it seems like the mechanism and the community are settling down into a regular rhythm. People know what it means to contribute, people know what to expect, and the results emerge in a relatively predictable pattern - even if which specific grants get the most funds is not so easy to predict. Stability of income So let's go straight into the analysis. One important property worth looking at is stability of income across rounds: do projects that do well in round N also tend to do well in round N+1? Stability of income is very important if we want to support an ecosystem of "quadratic freelancers": we want people to feel comfortable relying on their income knowing that it will not completely disappear the next round. On the other hand, it would be harmful if some recipients became completely entrenched, with no opportunity for new projects to come in and compete for the pot, so there is a need for a balance. On the media side, we do see some balance between stability and dynamism: Week in Ethereum had the highest total amount received in both and the current round. EthHub and Bankless are also near the top in both the current round and the previous round. On the other hand, Antiprosynthesis, the (beloved? notorious? famous?) Twitter info-warrior, has decreased from $13,813 to $5,350, while has from $5,851 to $12,803. So some churn, but also some continuity between rounds. the previous round Chris Blec's YouTube channel increased On the tech side, we see much more churn in the winners, with a less clear relationship between income last round and income this round: Last round, the winner was Tornado Cash, claiming $30,783; this round, they are down to $8,154. This round, the three roughly-even winners are ($4,631 contributions + $15,704 match = $20,335 total), ($16,084 contributions + $9,046 match = $25,128 total) and ($58,566 contributions + $7,893 match = $66,459 total), in the latter case the bulk coming from one contribution: Samczsun Arboreum 1inch.exchange In the previous round, those three winners were not even in the top ten, and in some cases not even part of Gitcoin Grants at all. These numbers show us two things. First, large parts of the Gitcoin community seem to be in the mindset of treating grants not as a question of "how much do you deserve for your last two months of work?", but rather as a one-off reward for years of contributions in the past. This was one of the strongest rebuttals that I received to my : that the people who contributed to that award did not see it as two months' salary, but rather as a reward for years of dedication and work for the Ethereum ecosystem. In the next round, contributors were content that the debt was sufficiently repaid, and so they moved on to give a similar gift of appreciation and gratitude to Chris Blec. criticism of Antiprosynthesis receiving $13,813 in the last round That said, not everyone contributes in this way. For example, Prysm got $7,966 last round and $8,033 this round, and Week in Ethereum is consistently well-rewarded ($16,727 previous, $12,195 current), and EthHub saw less stability but still kept half its income ($13,515 previous, $6,705 current) even amid a 20% drop to the matching pool size as some funds were redirected to public health. So there definitely are some contributors that getting almost a reasonable monthly salary from Gitcoin Grants (yes, even these amounts are all serious underpayment, but remember that the pool of funds Gitcoin Grants has to distribute in the first place is quite small, so there's no allocation that would seriously underpay most people; the hope is that in the future we will find ways to make the matching pot grow bigger). are not Why didn't more people use recurring contributions? One feature that was tested this round to try to improve stability was recurring contributions: users could choose to split their contribution among multiple rounds. However, the feature was not used often: out of over 8,000 total contributions, only 120 actually made recurring contributions. I can think of three possible explanations for this: People just don't want to give recurring contributions; they genuinely prefer to freshly rethink who they are supporting every round. People would be willing to give more recurring contributions, but there is some kind of "market failure" stopping them; that is, it's collectively optimal for everyone to give more recurring contributions, but it's not any individual contributor's interest to be the first to do so. There's some UI inconveniences or other "incidental" obstacles preventing recurring contributions. In a recent call with the Gitcoin team, hypothesis (3) was mentioned frequently. A specific issue was that people were worried about making recurring contributions because they were concerned whether or not the money that they lock up for a recurring contribution would be safe. Improving the payment system and notification workflow may help with this. Another option is to move away from explicit "streaming" and instead simply have the UI provide an option for repeating the last round's contributions and making edits from there. Hypothesis (1) also should be taken seriously; there's genuine value in preventing ossification and allowing space for new entrants. But I want to zoom in particularly on hypothesis (2), the coordination failure hypothesis. My explanation of hypothesis (2) starts, interestingly enough, with a defense of (1): why ossification is genuinely a risk. Suppose that there are two projects, A and B, and suppose that they are equal quality. But A already has an established base of contributors; B does not (we'll say for illustration it only has a few existing contributors). Here's how much matching you are contributing by participating in each project: Clearly, you have more impact by supporting A, and so A gets even more contributors and B gets fewer; the rich get richer. Even if project B was , the greater impact from supporting A could still create a lock-in that reinforces A's position. The current everyone-starts-from-zero-in-each-round mechanism greatly limits this type of entrenchment, because, well, everyone's matching gets reset and starts from zero. somewhat better However, a very similar effect also is the cause behind the market failure preventing stable recurring contributions, and the every-round-reset . Look at the same picture above, except instead of thinking of A and B as , think of them as . actually exacerbates it two different projects the same project in the current round and in the next round We simplify the model as follows. An individual has two choices: contribute $10 in the current round, or contribute $5 in the current round and $5 in the next round. If the matchings in the two rounds were equal, then the latter option would actually be more favorable: because the matching is proportional to the square root of the donation size, the former might give you eg. a $200 match now, but the latter would give you $141 in the current round + $141 in the next round = $282. But if you see a large mass of people contributing in the current round, and you expect much fewer people to contribute in the second round, then the choice is not $200 versus $141 + $141, it might be $200 versus $141 + $5. And so you're better off joining the current round's frenzy. We can mathematically analyze the equilibrium: So there is a substantial region within which the bad equilibrium of everyone concentrating is sticky: if more than about 3/4 of contributors are expected to concentrate, it seems in your interest to also concentrate. A mathematically astute reader may note that there is that involves splitting but at a ratio different from 50/50, which you can prove performs better than either full concentrating the even split, but here we get back to hypothesis (3) above: the UI doesn't offer such a complex menu of choices, it just offers the choice of a one-time contribution or a recurring contribution, so people pick one or the other. always some intermediate strategy or How might we fix this? One option is to add a bit of continuity to matching ratios: when computing pairwise matches, match against not just the current round's contributors but, say, 1/3 of the previous round's contributors as well: This makes some philosophical sense: the objective of quadratic funding is to subsidize contributions to projects that are detected to be public goods because multiple people have contributed to them, and contributions in the previous round are certainly also evidence of a project's value, so why not reuse those? So here, moving away from everyone-starts-from-zero toward this partial carryover of matching ratios would mitigate the round concentration effect - but, of course, it would exacerbate the risk of entrenchment. Hence, some experimentation and balance may be in order. A broader philosophical question is, is there really a deep inherent tradeoff between risk of entrenchment and stability of income, or is there some way we could get both? Responses to negative contributions This round also introduced negative contributions, a feature proposed in my . But as with recurring contributions, very few people made negative contributions, to the point where their impact on the results was negligible. Also, there was active opposition to : review of the previous round negative contributions The main source of opposition was basically what I predicted in the previous round. Adding a mechanism that allows people to penalize others, even if deservedly so, can have tricky and easily harmful social consequences. Some people even opposed the negative contribution mechanism to the point where they took care to give positive contributions to everyone who received a negative contribution. How do we respond? To me it seems clear that, in the long run, mechanism of filtering out bad projects, and ideally compensating for overexcitement into good projects, will have to exist. It doesn't necessarily need to be integrated as a symmetric part of the QF, but there does need to be a filter of some form. And this mechanism, whatever form it will take, invariably opens up the possibility of the same social dynamics. So there is a challenge that will have to be solved no matter how we do it. some One approach would be to hide more information: instead of just hiding made a negative contribution, outright hide the fact that a negative contribution was made. Many opponents of negative contributions explicitly indicated that they would be okay (or at least more okay) with such a model. And indeed (see the next section), this is a direction we will have to go anyway. But it would come at a cost - effectively hiding negative contributions would mean not giving as much real-time feedback into what projects got how much funds. who Stepping up the fight against collusion This round saw much larger-scale attempts at collusion: It does seem clear that, at current scales, stronger protections against manipulation are goingto be required. The first thing that can be done is adding a stronger identity verification layer than Github accounts; this is something that the Gitcoin team is already working on. There is definitely a complex tradeoff between security and inclusiveness to be worked through, but it is not especially difficult to implement a first version. And if the identity problem is solved to a reasonable extent, that will likely be enough to prevent collusion at current scales. But in the longer term, we are going to need protection not just against manipulating the system by making many fake accounts, but also against collusion via bribes (explicit and implicit). is the solution that I proposed (and Barry Whitehat and co are implementing) to solve this problem. Essentially, MACI is a cryptographic construction that allows for contributions to projects to happen on-chain in a privacy-preserving, encrypted form, that allows anyone to cryptographically verify that the mechanism is being implemented , but prevents participants from being able to prove to a third party that they made any particular contribution. Unprovability means that if someone tries to bribe others to contribute to their project, the bribe recipients would have no way to prove that they actually contributed to that project, making the bribe unenforceable. Benign "collusion" in the form of friends and family supporting each other would still happen, as people would not easily lie to each other at such small scales, but any broader collusion would be very difficult to maintain. MACI correctly However, we do need to think through some of the second-order consequences that integrating MACI would introduce. The biggest blessing, and curse, of using MACI is that contributions become hidden. Identities necessarily become hidden, but even the exact timing of contributions would need to be hidden to prevent deanonymization through timing (to prove that contributed, make the total amount jump up between 17:40 and 17:42 today). Instead, for example, totals could be provided and updated once per day. Note that as a corollary negative contributions would be hidden as well; they would only appear if they exceeded all positive contributions for an entire day (and if even that is not desired then the mechanism for when balances are updated could be tweaked to further hide downward changes). you The challenge with hiding contributions is that we lose the "social proof" motivator for contributing: if contributions are unprovable you can't as easily publicly brag about a contribution you made. My best proposal for solving this is for the mechanism to publish one extra number: the amount that a particular participant contributed (counting only projects that have received at least 10 contributors to prevent inflating one's number by self-dealing). Individuals would then have a generic "proof-of-generosity" that they contributed some specific amount, and could publicly state (without proof) what projects it was that they supported. But this is all a significant change to the user experience that will require multiple rounds of experimentation to get right. total total Conclusions All in all, Gitcoin Grants is establishing itself as a significant pillar of the Ethereum ecosystem that more and more projects are relying on for some or all of their support. While it has a relatively low amount of funding at present, and so inevitably underfunds almost everything it touches, we hope that over time we'll continue to see larger sources of funding for the matching pools appear. One option is , another is that new or existing token projects looking to do airdrops could provide the tokens to a matching pool. A third is transaction fees of various applications. With larger amounts of funding, Gitcoin Grants could serve as a more significant funding stream - though to get to that point, further iteration and work on fine-tuning the mechanism will be required. MEV auctions Additionally, this round saw Gitcoin Grants' first foray into applications beyond Ethereum with the health section. There is growing interest in quadratic funding from local government bodies and other non-blockchain groups, and it would be very valuable to see quadratic funding more broadly deployed in such contexts. That said, there are unique challenges there too. First, there's issues around onboarding people who do not already have cryptocurrency. Second, the Ethereum community is naturally expert in the needs of the Ethereum community, but neither it nor average people are expert in, eg. medical support for the coronavirus pandemic. We should expect quadratic funding to perform worse when the participants are not experts in the domain they're being asked to contribute to. Will non-blockchain uses of QF focus on domains where there's a clear local community that's expert in its own needs, or will people try larger-scale deployments soon? If we do see larger-scale deployments, how will those turn out? There's still a lot of questions to be answered. This article was originally published as “ ” ‘Gitcoin Grants Round 5 Retrospective

Reviewing the Gitcoin Grants Round 5

The massive undertaking of Ethereum 2.0 has gained the following other blockchains should be envious of. Ethereum staking has wildly increased in popularity, and at the time of writing, Etherscan shows it has accumulated more than . Ethereum forms part of everyone’s vocabulary when it comes to blockchain, DeFi, or crypto, and with the way things have been evolving, it reigns supreme among the rest. $13 billion worth of Ether Alongside the anticipation of the network’s overhaul from a Proof-of-Work to a Proof-of-Stake architecture, comes the ability to stake and validate transactions, whilst earning ETH as a reward. Ethereum 2.0 staking has attracted a market eager to lock in their ETH to be able to participate in the decentralisation of the network, but where do you start? has created a seamless approach to offering non custodial investment-grade Ethereum 2.0 staking products and services - whether its hosting nodes or pooling ETH through their innovative ‘Staking Club’. Above all, though, Launchnodes’ use of Amazon’s cloud (AWS) to deliver and sell their products and services has put them at the forefront of ETH2 staking, so it seems appropriate to delve into how crypto staking pioneers and enterprise clients can use them. Launchnodes Ethereum Staking with Launchnodes Ethereum staking clearly shows no signs of slowing down, and those who are as experienced as Launchnodes within the industry, have developed products and services aimed at enterprise and individual clients looking to kick-start their staking venture. Whether you’re just entering the sphere, a seasoned pro, or an enterprise wanting to join in on the Ethereum 2.0 buzz, it’s good to be aware of what companies like Launchnodes have been developing, and what’s available to ETH2 staking enthusiasts: Ethereum staking Ethereum 2.0 Validator Node on AWS (Personal Set-Up) Ethereum 2.0 Beacon Node on AWS (Personal Set-Up) Ethereum 2.0 Validator Node on AWS (End-to-End Set Up by Launchnodes) Ethereum 2.0 Beacon Node on AWS (End-to-End Set Up by Launchnodes) Ethereum 2.0 Beacon Node as a Service (by Launchnodes) Technical Assessment (of existing infrastructure) Whitelabel DeFi Solutions Design Staking Club (ETH2 staking pool for clients with less than 32ETH) Launchnodes have dived headfirst into offering and collaborate on the Ethereum 2.0 Proof-of-Stake blockchain. Participation is crucial to supporting Ethereum 2.0’s decentralised network, and the company certainly welcomes you into the community by providing guidance and support throughout the whole process. Whether it’s your Beacon or Validator node set up on or off AWS, or you simply don’t meet the 32ETH requirements, Launchnodes is bound to have the solution. non-custodial and fully independent opportunities to stake Ethereum Why Stake Independently? Benefits of staking independently Using your own personal PC for running Validator nodes is still a way of achieving 100% of the rewards, but it comes with so much more risk. It requires substantial technical know-how, ongoing monitoring and management, and a rather expensive set-up, if you really want to get the most out of it. Aside from this, though, issues could arise when trying to maintain connectivity so that your server doesn’t miss a single attestation - especially when you consider the frequency of slow internet connections, power cuts, and so on. Furthermore, an incorrectly set up validator node could lead to ‘slashing’ and extortionate non-performance fees, sometimes adding up to a whopping 50% loss on your staked ETH amount! Staking independently means eliminating all intermediaries, giving you the chance to generate the highest yield by running your own Validator node. Doing this still lets you , but with much more peace of mind, and though it might not be the most well-known approach to staking ETH (yet!), it is the most advantageous. On an even more intriguing note, Launchnodes is also the only provider of non-custodial on a turnkey basis, simplifying the process through cloud computing on AWS. Their Staking Club also offers you the chance to pool ETH between a group, so you can avoid having to lock in the full 32ETH required when you usually stake independently. reap 100% of the ETH rewards Ethereum 2.0 staking Ethereum 2.0 Beacon Nodes The Beacon Chain is the ultimate coordinator of the Ethereum network and is what introduces Proof-of-Stake. High-performing , capable of supporting multiple validator clients and communicating with other Beacon nodes. Launchnodes respects the investment-grade mindset demanded by , and the customer is always using their own AWS account that Launchnodes never has access to.  Launchnodes supplies clients with a container-based product to connect to the Beacon Chain by running and hosting their own on Amazon’s cloud server - AWS. This has opened the doors to independent infrastructure, and the potential for developing your own Ethereum staking architecture - however you choose. Launchnodes’ ETH2 Prysmatic Beacon Node is ‘always on’, connecting to Validator nodes, so you’ll be well on your way to earning 100% of your ETH rewards in no time. Beacon nodes are essentially the building blocks and backbone of the Ethereum 2.0 network Ethereum 2.0 staking Beacon node Beacon Node as a Service As the latest addition to the Launchnodes’ suite of , Launchnodes also offers , where existing validator nodes both on and off AWS can be connected to Launchnodes’ Beacon nodes. The service lets customers connect one or multiple validator nodes to a Beacon node that is synchronized with the beacon chain, and is always on, monitored 24/7 by Launchnodes engineering team. Ethereum staking services Beacon Node as a Service runs the latest version of the Prysmatic Client Each beacon node is never connected to more than 50 Validator nodes and boasts strategic geographic placement to minimize latency. Finally, the service drastically simplifies technical requirements for ETH2 staking and provides . This then removes the infrastructure and connectivity costs and makes non-custodial staking much cheaper compared to running your own individual beacon node, synching it to the Beacon Chain and then monitoring and managing it. secure infrastructure with 99.999% uptime When it comes to investment grade staking, it is imperative to run an infrastructure that the institution owns themselves and can rely on. This is where Launchnodes Beacon nodes , serving as an additional aid to safety and security. In other words, regardless of whether you run your own validator node or looking for a turnkey solution, Launchnodes is fully equipped to cover all your needs. can be used as a backup to already existing Ethereum staking architectures Ethereum staking Ethereum 2.0 Validator Nodes Via these Beacon nodes, Validator nodes can link to the Beacon Chain, conducting transaction attestations and earning rewards. Picture these Validator nodes as good old-fashioned miners, working behind-the-scenes, around the clock, with an endless amount of energy. Although you can run Validator nodes from a personal PC,  an array of disadvantages comes with it, including missing attestations and incurring slashing fees (in case your ETH2 validator node is not set right). However, if these nodes are run on the cloud, the risks of downtime are greatly reduced. This is why Launchnodes proudly boasts an ‘always-on’ Prysmatic , that runs on Amazon’s AWS cloud. Although it and purchase the node before you subscribe, it’s a powerful cloud solution to help you avoid any downtime and scary penalties. Launchnodes’ efficient Concierge Service will also offer end-to-end set-up and support to any individuals or organisations who are keen to obtain Validator nodes on their AWS accounts. What’s more, is that they can even review your set-up if the Validator node was purchased through Launchnodes. Validator node for Ethereum 2.0 requires you to have an AWS account Additionally, some may choose to run more than one Validator node, so Launchnodes’ services can continue to support the demand from individual and institutional clients. The amount of organisations participating in has notably increased, and includes the likes of - so why not you? If Launchnodes are there to take you by the hand and steer you towards true investment grade independent staking, then why rely on third-party Ethereum staking service providers who take a lump of your ETH rewards and in most cases get full control over your holdings? ETH2 staking banks, public and private companies, pension funds, and ‘the guy next door’ Ethereum DeFi and Staking, Product and Technical Assessment Apart from the aforementioned services, Launchnodes also provides enterprise clients with a strategy and technology review, assessing clients ETH 2.0 and DeFi staking solutions and service propositions technically and functionally. Launchnodes provides clients with a functional and of internal and client facing staking and ETH based defi propositions, using an their framework. technical assessment Staking Club Ethereum users were always traditionally required to lock in a minimum of 32ETH to validate blocks, however, Launchnodes’ offers the to still get involved with the decentralisation of the Ethereum 2.0 network.  With Launchnodes, you can pool in with others to combine a total of 32ETH to launch your own Validator node and stake directly. Once you have your 32ETH deposit, you’re , right off the bat. Launchnodes’ Staking Club is specifically designed to be a fully independent Ethereum 2.0 Staking medium, delivering 100% of the Staking rewards to clients, setting up the node and providing on going management and support. Staking Club opportunity for those that have less than 32ETH eligible for 100% of the rewards It is important to note that Staking Club is designed with institutions in mind too. If, for example, a company is looking to stake ETH2 for the benefit of its employees, Staking Club allows each employee to accumulate returns, instead of getting the yield in bulk and then figuring out/arguing about how to distribute it. Overall, is a relatively simple concept, which is perhaps why it has gained momentum and become a hot topic among crypto fans who are keen to invest in the future of Ethereum. Launchnodes’ products and services are , so it makes it the most lucrative option for entry-level or institutional enthusiasts alike. Ethereum 2.0 staking fully independent, non-custodial and deliver 100% staking APY Why Cloud Staking prevails over running your own servers In parallel with independent staking, servers is undoubtedly becoming the favoured choice, with the many benefits it possesses outweighing those of using your own servers. Ethereum staking via cloud - To start with, due to the professional node infrastructure, there are no missed attestations should your server disconnect. No missed attestations and zero downtime - You will still receive 100% of the Ethereum 2.0 staking rewards. No third-party involvement - A cloud-based staking service provider, like Launchnodes, will offer end-to-end set-up and support, so although you’re independent, you aren’t alone. No technical knowledge required - Cloud staking is much cheaper, since there are no expenses required to purchase a server or additional hardware. More cost-effective - Mining Ether requires a significant amount of energy, which could be reduced by making use of cloud servers that are already functioning and present. More sustainable Summary Ethereum staking has been Launchnodes’ focus since the beginning and is ascertaining its dominance due to its investment-grade, non-custodial, risk-reducing, and AWS cloud-based staking services. The mix of reliable infrastructure and selling through AWS means that individuals and enterprises are able to run Beacon and Validator nodes effortlessly, without owing commissions on ETH staking services, depending on any third-parties or even being obliged to deposit the entire 32ETH. Ethereum 2.0 staking is rapidly gaining momentum, and Launchnodes is maintaining the pace, offering a silver-service, holistic approach that takes clients on their very first Ethereum staking strides, right up to deploying hundreds of ETH nodes.

Ethereum 2.0 staking on AWS: Cloud Staking Matters

After months of anticipation, Cryptex announced the launch of TCAP, The World’s First Total Cryptocurrency Market Cap Token. Real-time price exposure to the entire Cryptocurrency sector in a single solution. The entire market. Yours at the push of a button. TCAP is not a fixed basket of tokens. TCAP is not an ICO, nor a rebased elastic. TCAP is a new, 250% fully backed, fully collateralized asset that’s both audited and accurately representative of the entire cryptocurrency complex by total market capitalization. Our team has been hard at work on this concept for the past 14 months. Today, we’re proud to say our vision is now a reality. TCAP is currently live on Rinkeby testnet powered by decentralized Chainlink oracles that provide real-time total market cap crypto data aggregated from many of the most reputable crypto data providers in the world, bringing reliable, tamperproof data on-chain to our TCAP smart contract. How Does TCAP Work? As of this writing, the total crypto market cap currently resides at 650 billion dollars. Our smart contracts call the exact total market cap from Chainlink’s price reference contract, and then add a divisor to that number, just like the S&P 500 or any major financial index would. The price calculation for TCAP is as follows: = $650,000,000,000 c = 10,000,000,000 d = = $65.00 r c Where is the total cryptocurrency market cap, is the divisor and is the TCAP token price. c d r TCAPs are then minted upon being collateralized by an underlying asset, such as ETH, WBTC, or DAI. What the user receives in return is a newly minted asset represented by a token that moves in real-time to the penny of the underlying total market cap metric our smart contract is tracking. Each TCAP is algorithmically collateralized by a corresponding amount of ETH, WBTC, or DAI needed to appropriately back each token by 250%, thus creating price exposure to the entire cryptocurrency sector with the single push of a button. Understanding Cryptex Cryptex is laser-focused on building innovative, open-source financial products for the global Crypto community. Using Ethereum’s smart contract system, Cryptex is able to build decentralized financial instruments such as Total Market Cap Token and many more others soon to come. Pairing real-world data supplied on the Ethereum blockchain alongside collateralized backings for generating innovative new tokens, we’re introducing DeFi products that were previously not possible without a centralized custodian or manager. Now, Cryptex is providing the framework for decentralized financial products that offer exposure to more than just BTC, ETH, and other DeFi tokens. Why Chainlink Oracles? Chainlink has established itself as the industry standard decentralized oracle solution, becoming the most widely used and fastest-growing price oracles within the DeFi ecosystem, currently securing 4B+ in value. Chainlink’s Price Feed framework employs decentralization at both the oracles and data source levels to ensure no single point of failure in data delivery and sourcing. Chainlink’s decentralized oracles source price data from premium off-chain data aggregators and broadcast it on-chain using a network of independent, Sybil resistant node operators run by leading blockchain DevOps and security teams. Through this framework, TCAP smart contracts can obtain highly available, accurate, tamperproof market cap data to ensure fair pricing for TCAP. Preston Van Loon, Co-Founder and Blockchain Lead for Cryptex and Co-Founder of Prysmatic Labs says “TCAP is an exciting new asset that demands precise data on-chain. Chainlink enables Cryptex to aggregate multiple data points from external sources within the smart contract framework on Ethereum. Using a trust minimized oracle framework allows TCAP to minimize the trust of Cryptex and ultimately enables us to create better trustless financial products.” Joe Sticco, Co-Founder and CEO of Cryptex says “The beauty of working with Chainlink is they provide us with decentralized total crypto market cap data, which via the TCAP smart contract, we can then algorithmically match up on chain to cross-asset collateral for creating not only our initial TCAP token but a forthcoming lineup of fully decentralized data-backed financial tokens for the entire ecosystem.” Experience TCAP on Testnet Join over 500 people that have already committed to experiencing TCAP on testnet by following the steps in . this post Follow Cryptex You can keep up with Cryptex on , , and . You can access the technical documentation, whitepaper, and Quantstamp audit by visiting the . Twitter Reddit Discord Cryptex website Follow the Chainlink Network Chainlink is trusted to deliver definitive truth by hundreds of organizations to provide continuous, reliable data feeds. To learn more, visit and follow on Twitter. chain.link @chainlink | | | | | | | | | Website Twitter Discord Reddit YouTube Telegram Events GitHub Price Feeds DeFi Also published at https://medium.com/cryptexfinance/cryptex-selects-chainlink-to-power-its-flagship-token-tcap-71461e73579f

Chainlink is Set to Power Cryptex's Flagship Token, TCAP

Ethereum 1.0 was a landmark moment in blockchain technology. Allowing for the trustless execution of code on a blockchain in its current form, however, it does not have the ability to scale to the level of computation that would be needed to disrupt current financial systems. With the evolution of Ethereum 2.0, it will usher in the new era of . "Broadband Blockchain" As part of this upgrade, Ethereum is changing some of the most foundational components of its system, most notably, its consensus algorithm. A consensus algorithm is the mechanism used to come to agreement on the state of the blockchain. Ethereum 1.0 uses the now famous Proof of Work (or Nakamoto) consensus mechanism. This method is extremely energy intensive, with Bitcoin and Ethereum together consuming more energy coming to consensus than the entire annual .  Ethereum 2.0 will instead use Proof of Stake consensus.In simple terms, if PoW consensus is a guessing game trying to find a magic number, PoS consensus is an organised voting system where everyone keeps a large sum of money in escrow, and if they misbehave, some of their escrowed money is taken off of them (called slashing). energy consumption of Switzerland The users that take part in this proof of stake system are called stakers, and they lock up 32 ether into the escrow contract and deploy small servers on the internet called validators to perform the duties of a staker in exchange for rewards. The rewards vary depending on the number of people taking part, but roughly vary between the margins of 2% to 18% APR. Ethereum 2.0 had its Genesis block on December 1st 2020. At launch there was more than $400m worth of Ether locked into this escrow, and there were 21,063 validators in operation, each communicating with each other through beacon nodes using peer to peer communication across the internet. The infrastructure to run all of these validators is immense, and the security and reliability of these systems is of utmost importance, as any downtime results in a loss of earnings or even a loss of the principal sum escrowed. Blockdaemon has been developing secure and scalable non-custodial Eth2 Staking Infrastructure for its enterprise clients, and today we're sharing a few pro tips to maximise the safety and performance of your enterprise-grade staking infrastructure. Let clients control their withdrawal key By default, each of the Eth2 clients (Prysm, Lighthouse, Teku, Nimbus etc.) create withdrawal keys and validating keys from the same mnemonic phrase. This is the easiest way to get started, but if you are building an enterprise staking solution for customers, this means you are taking full custody of their funds. This has major security and legal implications. Instead, have your clients create an Eth2 address they control, and use a tool like to craft a custom deposit data file that allows your enterprise's validator to withdraw to the client's withdrawal address. This way, if your validating server is compromised, the attacker can force you to exit the validator (with or without getting slashed in the process), but the exited funds will be sent to your client's cold wallet, which the attacker should not be able to access because it should be nowhere near your compromised validator--thus limiting potential damage. If an attacker can only burn your client's funds, but cannot steal them, they are less incentivised to attack your validating stack relative to other custodial enterprise staking solutions. ethdo Have robust monitoring and alerting for your validator If your validator goes offline, how long would it take you to notice? Make sure to invest in monitoring infrastructure that can watch your validator's participation in the network, as well as some of the more general server management risks like running out of free disk space on your device, your CPU getting overloaded, your server clock falling out of sync or your validator running out of free memory to use. It is important to remember that monitoring without alerting is not sufficient. If you have to actively check your monitoring to know if there is an issue, you are likely to get complacent as the months go by, and sooner or later you could miss a long period of inactivity that would have been avoidable had you integrated prometheus or or any of a number of alerting tools into your enterprise stack. alert-manager opsgenie Consider remote key signers As of writing this post, the , and clients all have the ability to integrate with remote key signing infrastructure. These services store your private keys in an encrypted and secure fashion, and make it even more difficult for a hacker to extract your precious private keys. is an enterprise solution from for fault tolerant and secure key management of Eth2 validating keys that might make your enterprise staking solution more robust. Prysm Lighthouse Teku Dirk Attestant Defend yourself against DoS attacks with Sentry Nodes Currently, a significant concern when it comes to Eth2 staking is that it is relatively trivial to correlate validators to the IP address of the beacon node they attach to. Although the validators themselves should not be exposed to the internet, their beacon nodes are, and with this knowledge, it becomes feasible to selectively DoS the beacon node that owns a validator that's about to propose a new block. This means a malicious attacker can prevent your validator from doing its duties by overloading the beacon node it's attached to for about 12 seconds every 6 minutes when your validator is due to make an attestation or block proposal. To mitigate this issue, one can design an array of publicly accessible beacon nodes that act as sentries, and the beacon node your validators attach to is not publicly accessible over the internet and instead it peers with only your sentry nodes. This means an attacker needs to simultaneously DoS every one of these nodes to keep your validator offline, otherwise one of them will be able to relay your validators attestations to the wider network successfully. Be client agnostic In August 2020, a bug in the Prysm client's clock management code caused every Prysm client to go offline, resulting in more than 60% of the Medalla testnet validators going offline. This problem was exacerbated when an emergency release to solve the problem was broken, rendering the prysm validators unusable on that version, requiring a downgrade to rectify. In an emergency situation where a specific client becomes unusable, it helps tremendously to be able to run your staking system using more than one of the clients. Interoperability of clients is a strong priority amongst the Eth2 teams, and through their hard work it is becoming achievable to be able to replace a Prysm validator with a Teku validator, or a Lighthouse validator seamlessly. With multiple supported client implementations, your company, and your users, are more protected than if your entire infrastructure relies on just one Ethereum 2.0 client. Practice, practice, practice No system is fully reliable, no system has 0 downtime forever. Don't be afraid to break your testnet systems so that you can work on your recovery skills. Make it fun, make a red team and blue team out of your engineers and incentivise them to break their own infrastructure. Develop playbooks for handling the different types of faults so when they happen in production people immediately know how to remedy the situation. Build experience and confidence in your team that they can successfully manage this brand new infrastructure in a brand new threat landscape. Mistakes happen, but not learning from your mistakes is probably the worst one of all. To learn more about how you can participate in Ethereum 2.0 with us, visit our for more information. marketplace By Oisin Kyne, Developer at Blockdaemon

How To Build A Secure Eth2 Staking Infrastructure

This article will guide you through running ETH2.0 Beacon Node with Lighthouse client on MacOS if you have barely to 0 experiences with Terminal command lines and you want to spin off Lighthouse Beacon node and join the validator pool on ETH2.0 Beacon chain with Lighthouse client. This guide includes spinning off Nethermind Goerli node. The goal of this article is to guide you through becoming a validator without the need to reach out to teams so you can post “ ” kinda tweet when you manage to spin off your Beacon node (make sure to tag me if you use this guide). This guide can’t be used to run other clients as there may be differences when running different ETH1 clients to run Goerli node and other ETH2.0 clients to run Beacon node. This is exciting You may experience running into a bugs. Don’t worry about bugs, make sure to report them to teams if you experience some :) If you will get stuck, reach out to the teams- they’re happy to assist you. Note: Intro Ethereum has recently (July 30th) since genesis block of ETH1 chain was mined. Today, August 4th 1pm UTC ETH2.0 Medalla testnet will go live. This is super exciting moment for Ethereum community as the road to ETH2.0 is going public will start processing attestations and blocks on Proof-Of-Stake mechanism. This is the beginning of the slot zero of epoch zero. Important note — Medalla is just Testnet, which means that you’re going to use Goerli testnet gETH to stake and join Medalla Validator pool. Not a real mainnet ETH. celebrated it’s 5th Birthday If you’re interested to dive more into ETH2.0 I highly recommend you to check out by Danny Ryan The State of ETH2, June 2020 TL:DR of what we are going through in this guide Install Developer Libraries Spin off ETH1 Goerli node Make deposit via Launchpad Pick ETH2.0 client Install Lighthouse Developer Libraries Run Lighthouse Beacon Node Run Lighthouse Validator Client Additional Reading Install Developers libraries📚⌨️ This is just a basic installation of what we need in order to spin off ETH1 Goerli node and make deposit on ETH2.0 chain via d. We will do some installation later, as every ETH2.0 client have different requirements on what needs to be installed in order to run their client. Launchpa You will need to install a few developer libraries at first. In order to have no struggles, neither “red lines” — errors in Terminal window, you should head over to “Security & Privacy” window on your Mac and select “Open Anyway” as you may experience that some apps are not notarised by Apple, which may cause you some headache moments. Use for a better explanation with screenshots. You will need this step to enable Nethermind runner — we will go through this step later. You may need this step to enable Homebrew or other libraries, programming languages. this guide — This is the magic that will help you install and run other programs on your MacOS. This is the basic you need in order to be able to run next programs and help you with installation process. Copy paste this into your Terminal: Homebrew brew install gmp && brew install snappy && brew install lz4 — this is general-purpose cryptographic library that Lighthouse, and I believe other ETH2.0 clients are using. Copy paste into Terminal: OpenSSL brew install openssl I hope that you made it through this important step, it will be just simpler 🙂 Goerli Node Goerli node is well supported across all ETH 1.0 clients, tooling, and infrastructure, and is used to test the ETH 2.0 transition through a deposit contract deployed to Goerli. You need to run Goerli testnet in order to make deposit contract that you upload as “deposit data” to launchpad that will allow you to stake on ETH2.0 Beacon chain. You have more options to pick which client to spin off in order to run Goerli node — the most used is , lighter one is . Geth Nethermind Note: Geth may be easier to spin off, Nethermind is lighter.You may experience some bugs which are not something that you can’t deal with. I found a great . There’s another . guide on how to spin off Lighthouse with Geth node guide on how to spin off Goerli Geth node Request gETH — Goerli ETH You will need gETH or Goerli ETH in order to stake on ETH2.0 Beacon node. There are multiple ways how to request for gETH: Go to and enter your ETH address Goerli Authenticated Faucet Go to that can give you 165 gETH every 6 hours Prysmatic Labs Discord Or ask on for gETH Lighthouse Discord Spinning off Nethermind Goerli node To spin off Nethermind Goerli node head over to downloads page and ETH1 client. Unzip file (click on it). You may experience some struggles as Nethermind is not notarized app by Apple so and enable “Nethermind.Launcher” file. Now paste into Terminal: download the latest version of Nethermind head over this guide rocksdb brew install Let the operation process then paste into Terminal: ./Nethermind.Launcher select Goerli (light Clinque testnet) select sync: Fast sync type: N to not configure eth stats You should be able to see this on your Terminal: 🥳 Now you should be able to get logs and run Goerli node This may take some time, depending on your internet bandwidth. Note: I recommend you to check out this guide by Nethermind on how to run Nethermind node and logs explanation. If you will experience some bugs, just restart the node by Control + C and type/paste into Terminal: ./Nethermind.Launcher And start this process again: select Goerli (light Clinque testnet) select sync: Fast sync type: N to not configure eth stats Feel free to reach out to Nethermind team on Gitter if you are stuck at this point. Make deposit via Launchpad 💸 This is pretty exciting part as you don’t need to deal with Terminal for a while. This is the part where you will deposit 32 gETH (Goerli ETH). Head over to (in your browser). Make sure to read the steps carefully although you’re going to stake just gETH which is testnet ETH (have no real value) but you still should be aware of what are you doing. Make sure to pay attention to Signing Keys (key management). Hit continue button. Open new Terminal window, at this point you should have 2 Terminal windows open — one with Goerli node, one which you will use to make deposit. Just copy paste this line into your second (new) Terminal window: Launchpad website ./deposit — chain medalla Now pick your mnemonic language — it doesn’t really matter which one you choose, you will get mnemonic worlds — randomly generated worlds in different language. English is nice by default but you can pick any from 7 languages. Type the language into your Terminal and make sure to save this mnemonic phrase somewhere offline. Now type the password, be careful there won’t be any appearance of you typing the password so I recommend you to use offline text editor to paste your password — you can use Notes, Word or anything other. Make sure to save this password as well as your mnemonic phrase Paste the password, hit enter. This cute Rhino should appear in your Terminal: Now continue on to the next step in Launchpad. Find “deposit-data- [timestamp — numbers].json file — windows will appear where you will find this file. You can find it in Finder User (your Mac username) → eth2.0-deposit-cli → validator_keys. This are the keystores that generated Rhino. Now you are going to make transaction on Launchpad. Make sure to select Goerli Test Network on your wallet and deposit Goerli ETH not mainnet ETH. Don’t worry about gas fees, this is not real Ether just test gETH and so the gas fees doesn’t matter at this point. Make a transaction and tadaaaa! Pick ETH2.0 Client There’s a by . I highly recommend you to go through it at least to get a big picture of why there are so many ETH2.0 clients so you will pick the one that you like the most. great overview of ETH2.0 Clients Somer Esat Lighthouse 💡🏠 Lighthouse is aiming to be the most secure ETH2.0 Client written in Rust. They provide where you can find which I believe may not be something that you’re familiar with. Lighthouse book a guide on running Validator in Docker In order to run Lighthouse ETH2.0 Client, you will need to: Install Lighthouse Developer Libraries Run Lighthouse Beacon Node Run Lighthouse Validator Client Install Lighthouse Developer Libraries 📚⌨️ You need to install Cmake — building tool and Rust — programming language and clone Lighthouse library in order to spin off — run Lighthouse Beacon Node and Validator Client. — is a building tool which is required by some libraries that are apart of Lighthouse install package that you need to download with extra command line. Copy paste into Terminal: Cmake brew install cmake — it is a programming language that Lighthouse is written in. You need to install rust in order to run Lighthouse client. Copy paste into Terminal: Rust curl — proto ‘=https’ — tlsv1. -sSf https: 2 //sh.rustup.rs | sl Clone Lighthouse library — you need to clone Lighthouse library in order to be able to run Lighthouse Beacon Node and Validator client. Copy paste into Terminal: git ://github.com/sigp/lighthouse.git cd lighthouse clone https Run Lighthouse Beacon Node The beacon node is a program that maintains the current state of the chain — network and talking to other peers — nodes on the network. Now back to your Terminal. You’re a few Terminal lines away — a few Terminal lines close to be ETH2.0 Medalla validator. At this point you should have open 2 Terminal windows — one with Goerli testnet running, one with ETH2.0 deposit client (where you had Rhino). Open new Terminal window and paste: — http — eth1 lighthouse bn This will start your Lighthouse Beacon node which is a program that maintains the current state of the chain by talking to other peers on the network. This is what you should see on your Terminal: Run Lighthouse Validator Client Now you Lighthouse Beacon Chain is running, let’s do the final step — run the Validator Client which will be used to validate blocks on the ETH2.0 network. In this step you will use Terminal with Rhino — eth2.0- deposit-cli. Paste into your Terminal: account validator — directory validator_keys lighthouse import Now you need to paste your password again (password the one word, not mnemonic phrase — many words). Your Terminal will show you many lines starting with: The last step The Validator Client (vc) is a program that holds your keys (one or more depending on how many validators you’re running) and signing messages (blocks) that you send to the network. Now you need to paste last thing into your Terminal, which will kick off the Validator Client. Use Terminal with Rhino — eth2.0-deposit-cli window and paste into this Terminal: lighthouse vc Congratulations ! You’re now ETH2.0 Lighthouse client Validator of Medalla network 🤗 I hope this article was educational and provided you all information you needed in order to join Lighthouse ETH2.0 Beacon node validator. Now you can make a about being apart of the network 😄 Tweet Make sure to save you mnemonic phrase and password in an offline storage. Additional reading There’s so much to read about ETH2.0, here’s a list of what I recommend you to check out. curated by ETH2.0 Newsletter Ben Edgington. ETH2.0 for Dummies If you’re interested in reading more about Launchpad, . check out this article What’s ETH2.0 and what will happen to this cryptocurrency This may be similar to this article but maybe a bit outdated — Using Nethermind to Run a Validator in Eth2 I also curated my own list of articles regarding to ETH2.0 There’s a guide on with Geth client how to run Lighthouse ETH2.0 validator Kudos to Sigma Prime Thank you so much for this opportunity to show you how to run Lighthouse validator for Non tech people. Thank you so much to for technical assistance, answering my questions during this process. It has been a blast to work with team, good luck with the Lighthouse ETH2.0 Client ! 🥳 Mehdi Zerouali Pawan Dhananjay Sigma Prime Thank you to from for helping me out with Goerli node. Tomasz K. Stańczak Nethermind Previously published at https://medium.com/@AnettRolikova/eth2-0-lighthouse-validator-non-tech-guide-on-macos-90cb00f7ba4f

How To Run An ETH 2.0 Beacon Node Using The Lighthouse MacOS Client

A high-level overview of one of Ethereum’s layer 2 solutions This article is the first in a series of high-level overviews of features, protocols and developments of different blockchains . In these overviews, I will attempt to provide relatively simple outlines of the topic, as well as some detail regarding their inner workings and practical applications. TL;DR In a hurry? No problem, here’s a general summary: Public blockchains, such as Ethereum, need to be able to scale in order to reach their ambitions of being recognised as a viable alternative to traditional systems, which, in-turn, will allow them to gain widespread adoption and application. These scaling solutions can be ‘built into’ the blockchain itself (layer 1 solutions) or ‘built on top of it’ to take some strain off the base chain (layer 2 solutions). These two solution categories will likely be complementary to each other. Plasma is a layer 2 solution for Ethereum that provides a framework for building ‘off-chain’ decentralised applications that are secure, scalable and swift. There are numerous implementations of Plasma, including: — A UTXO-based chain that possesses the basic principles of security and enables a higher transaction throughput for Ethereum. Minimal Viable Plasma (MVP) — Improves the user experience of MVP by lowering the number of actions required to make a transaction. More Viable Plasma (MoreVP) — A proof of concept that aims to reduce the complexity of Plasma, paving the way for more sophisticated protocols than just token transfers. Plasma Snapp — An implementation that utilises non-fungible tokens as a representation of fixed amounts of fungible ones. For example, if I deposit 5 ETH into the Plasma Cash chain, I receive a single token worth 5 ETH that cannot be merged or divided. Practical applications include collectible-based games and supply chain management and logistics. Plasma Cash — An implementation that is very similar to Plasma Cash, but allows partial payments. The most practical application would be for payments of any size, particularly micropayments. Plasma Debit — Soon to have a proof of concept, this will allow two different layer 1 blockchains to interact with each other via a shared Plasma chain, enabling atomic swaps. For example, the Plasma chain could act as a connection between the Ethereum and Ethereum Classic blockchains. Plasma Bridge Plasma is not Ethereum’s only proposed layer 2 solution and can be reasonably expected to coexist with — and, as with layer 1 solutions, complement — the other layer 2 solutions. Read on for the full article. A brief introduction to blockchain scalability Although people are becoming aware of the vast potential and many applications of blockchain technology, there are numerous hurdles in the way of public blockchains before they can achieve these ambitions. The most prominent problem is the scalability of the blockchain. Scalability is defined as . Although scalability is an assortment of challenges in the context of blockchain, discussion mainly revolves around the network’s transaction throughput. This is evident from the recent spotlights on Ethereum, which have focused on the network’s speed during times of congestion — predominantly caused by events such as initial coin offerings and . the capability of a system, network or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth games revolving around non-fungible tokens Layer 1 solutions One of the approaches for scaling these platforms is through modification of its base protocol, or ‘layer 1’. Due to their direct nature, these changes are generally enacted through a . hard fork An example of a layer 1 solution for Ethereum is , which solves the ‘one-track’ issue bottlenecking the network. Currently, node has to process transaction in sequence, limiting the network’s transaction throughput to the maximum that can be processed by each node. By splitting the chain into segments — or ‘shards’¹— this limit is lifted, as each node can then process different transactions in parallel with each other². ‘sharding’ every every Research and development work for sharding is fully underway by groups such as and the community in general, but the upgrade is not yet close to release. Prysmatic Labs ¹ Each shard is technically its own separate blockchain, each sharing the same consensus mechanism via a beacon chain and each able to communicate with other shards. ² Furthermore, once sharding is live, the shards are planned to use over the existing , which in itself will improve transaction throughput via the faster processing speed of smart contracts. This instruction-set also has the added benefit of making smart contracts more standardised and secure. eWASM EVM Layer 2 solutions Changes to the base layer of a blockchain can be incredibly difficult to execute, as the integrity and security of the protocol is paramount to its success. Due to this sensitivity, layer 2 solutions are also being developed which will complement the layer 1 methods in providing a scalable and efficient blockchain. Layer 2 solutions are not changes to the base protocol, but rather constructions built on top of it to allow operations to take place ‘off-chain’, while still retaining the benefits provided by the main chain, i.e. security and finality. An obvious benefit to layer 2 solutions is that a hard fork is not necessarily required for their implementation, but their scope is far larger than integration concerns; along with layer 1 solutions, they can dramatically improve the practical application and usability of the ‘base’ blockchain. There has been extensive research into layer 2 solutions since the initial concepts of — including , and Bitcoin’s — but perhaps the most promising³ layer 2 solution under development for Ethereum is ‘Plasma’. State Channels Raiden TrueBit Lightning Network ³ Note that there is no reason the different solutions cannot coexist; for example, Channels be built upon a Plasma implementation in the future due to their complementary attributes. I do, however, believe that Plasma will be able to establish itself as the most widely utilised layer 2 solution. may What is Plasma? is a framework for building decentralised applications (‘dApps’) that are secure, scalable and swift. Plasma Plasma allows dApps to achieve this through the creation of ‘child’ blockchains, which are connected to the ‘parent’ blockchain¹ through a smart contract. The dApps can then execute entirely on their respective child chains, dramatically lowering the strain placed on the parent chain and enabling the dApp to be more efficient and cost-effective. These child chains are full blockchains, with their own consensus mechanisms — likely to be (‘PoA’) or (‘PoS’) — but, like children, they are not fully independent of their parent. The child chain relies on the parent for security and so must periodically submit commitments to the smart contract that connects them. These commitments are details of the latest updates from the child chain and, as they are broadcast across the parent chain, i.e. the entire Ethereum network, they are crucially important. Proof of Authority Proof of Stake To ensure all these off-chain changes are final and binding, they need to be subject to a cryptographic primitive — a ‘ ’. Due to their size, however, committing applications in their entirety to the parent chain would make the use of Plasma obsolete. For this reason — as with other blockchain applications — ‘ ’ are used which, in-turn, allows the use of ‘Merkle proofs’. commitment scheme Merkle trees In simple terms, a allows the authentication of a small amount of data — such as a hash — to be extended to also authenticate a much larger database. applied Merkle proofs for the storage of transactions in each block, which facilitated Satoshi’s concept of ‘ ’. In Plasma, the commitments are the ‘root’ of the Merkle tree of each block, thus enabling the use of Merkle proofs for one of the framework’s defining security features — the ability for users to ‘exit’ the child chain. Merkle proof Bitcoin simplified payment verification Exiting the child chain means the user withdraws their funds back out to the parent chain and — through the application of a Merkle proof — can prove to the smart contract that they have the funds to withdraw. A key part of Plasma’s security is that the user has the right to withdraw to the parent chain at any time. ¹ Note that the use of ‘parent’ chain is for simplicity/visualisation purposes. The correct term is ‘root’ chain, as it is possible for a child chain to have their own child chains ad infinitum (technically making these child chains ‘parents’, but not ‘roots’). Every child chain will be a subject of the root chain, rather than the child chain above them in the hierarchy. Is Plasma secure? Layer 2 solutions rely on the base layer to provide their security, but they need mechanisms in place to protect the operations on their own chains too. In brief¹, Plasma has many theoretical security elements, the core of which revolves around the user being able to exit the child chain at any time, i.e. withdraw their funds back to the main Ethereum chain. This means that even if the child chain is completely centralised — and that central party decides to act maliciously — none of the users’ funds are at risk of being permanently lost. This safety comes from users being able to rely on the main chain as a source of truth, as well as from how any user can challenge any withdrawal from the child chain. When users want to exit the child chain, they need to submit an ‘exit’ transaction on the main chain — an ‘exit bond’ — and, in some implementations, they also need to include a Merkle proof to prove their ownership of the funds. Withdrawals from the child chain aren’t instant. Instead, they’re subject to a challenge period — an ‘exit challenge game’ — where any user can submit a ‘fraud proof’ to the main chain. The fraud proof contains data from a previous block that proves that the exit is invalid, as the funds trying to be withdrawn by the user have already been ‘spent’ by that user in a different block. Those who successfully prove the transaction is fraudulent are known as ‘bounty hunters’, as not only do they prevent the exit from happening, but they are also rewarded with the value of the bad actor’s exit bond. As you can probably imagine, off-chain security is a very complicated issue, with numerous . that seems to be apparent in MVP² ( ) is the responsibility of challenges and the scope of bounty hunters. For example, if I deposited £1000 into the child chain — giving me a starting point of £1000 — and sent one hundred thousand (100,000) transactions of 1p to other addresses under control, then the only parties that would care about fraudulent exits from those transactions — i.e. if I try to fraudulently exit some of those ‘spent’ UTXOs — would be myself (the bad actor) and, indirectly, the bounty hunters. theoretical problems One below UTXO my These fraudulent exits could occur at any point on the chain and, due to the number of transactions, a copy of the whole chain could be far too large for a regular PC to handle, severely limiting the pool of bounty hunters who can challenge my exits. From a data storage perspective, the answer could lie in a mechanism for in MVP, enabling widespread participation in all challenges as the period, ergo the data, would be limited to a reasonable amount. The question would then be about how users are to watch others’ transactions³. safe checkpointing incentivised Due to the importance of security, there is a lot of debate about how protection can be managed while still maintaining the highest levels of decentralisation. ¹ The details and issues surrounding Plasma’s security will be explored in detail in a future article. ² Note that this theoretical issue would not necessarily be applicable to Plasma Cash, due to the implementation’s requirement of historical ownership proof and token uniqueness mechanisms. ³ There are further questions surrounding this problem which won’t be addressed in this article, but as an example: all exits can be challenged if a user must put up a bond for every exit — but what would be the value of these bonds? Would they be a set value, or dynamic and proportional to the amount being transferred? The value of these bonds is critical in ensuring a balance between good user experience and incentivised bounty hunters. Implementations of Plasma As a framework, Plasma has nearly unlimited applications — the majority of which are still in the research stages. Below are very brief overviews of some of the latest proposed implementations of Plasma, which will be explored in greater technical detail in future articles. Minimal Viable Plasma (MVP) As the name suggests, is a UTXO-based chain that possesses the basic principles of security and enables high transaction throughput, but relies on users being able to willingly interact with, validate and exit the chain themselves. In these early stages, users will also have to have a certain level of trust in the operator, as MVP uses a PoA mechanism. Plasma MVP More Viable Plasma (MoreVP) builds upon MVP by improving the user experience. To transfer UTXOs in MVP, users would need to send them to another user’s address, wait for that transaction to be confirmed in a block and send a confirmation signature. Not only is this ‘double signature’ system onerous on users, it reduces the block space available for other transactions. MoreVP, in essence, removes the need for these confirmation signatures due to its adjustments to exit priority. More Viable Plasma then The is currently being expanded by the team at . MoreVP specification OmiseGo Plasma Snapp Currently at the proof of concept stage, aims to effectively remove much of the complexity of Plasma integration through the use of ‘ ’ (‘zk-SNARKS’), removing the need for confirmation signatures and even exit challenge games. Plasma Snapp zero-knowledge succinct non-interactive arguments of knowledge Vitalik has also on the use of zk-SNARKS in scaling, providing a proposal that wouldn’t require transacting parties to always be ‘online’. This makes progress in solving the data availability issues that would be present within current Plasma implementations, which is caused by their assumptions regarding eventual consensus¹. recently elaborated liveness ¹ In simpler terms, (‘PoW’) can essentially guarantee liveness, whereas other consensus mechanisms like PoA aren’t as guaranteed due to the requirement of ‘monitoring’. Proof-of-Work Plasma Cash is an implementation that utilises non-fungible tokens as a representation of fixed amounts of fungible ones. For example, if I deposited 25 ETH into the Plasma Cash chain’s contract, I would receive a token on the chain worth 25 ETH. Each token on Plasma Cash is attributed a unique ID upon creation and cannot be divided or merged with other tokens. Plasma Cash Plasma Cash blocks are also different to those seen in MVP. Plasma Cash blocks save a ‘slot’ for every token in existence on the chain, meaning users can not only see what has been sent in each block, but also what hasn’t been sent. This allows the formation of , which can act as a proof that a transaction part of a particular block. sparse Merkle trees isn’t As a slot in each block is unique to each token, no other token can be placed into that slot. This means that users only need to keep track of their own token(s), as no other tokens can enter their slots. This reduces the amount of data that needs to be transferred to clients, as they only need to download the data they are privy to, i.e. proof of their token history. One of the issues with Plasma Cash is in its general flexibility — tokens on the chain must always have a fixed denomination, preventing the transfer of fractions of tokens. Plasma Debit is very similar to Plasma Cash. One of the key differences is that it allows partial payments to be made, thus enabling arbitrarily denominated payments and, therefore, micropayments. Plasma Debit Plasma Debit is like a , where each token represents a bidirectional payment channel (as opposed to the deposit itself). Unlike the , the state of the channel is regularly notarised to the main chain, meaning these tokens can be transferred from one owner to another (as with Plasma Cash tokens). As these tokens are payment channels, this means that a new party can join the Plasma Debit payment network without having to perform an on-chain transaction themselves. Lightning hub Lightning Network Plasma Debit is most suitable for payments, as all transactions will be fast and cheap. One of the projects that is researching a (alongside their ) is the . Plasma Debit implementation Plasma Cash work Loom Network Plasma Bridge A theoretical project that should soon have a proof of concept, would be a way to connect two layer 1 blockchains together via a shared Plasma child chain. This would allow the conversion of different blockchain assets to a standard native token on the child chain, enabling free transfers of value between chains, i.e. . Plasma Bridge atomic swaps Interoperability of blockchains The interoperability of blockchains is another major discussion point for the future of the technology. Many people are fiercely loyal to their chosen chain, which can be detrimental to development progress as proponents fail to acknowledge their own chain’s objective weaknesses or other chain’s relative strengths. are aiming to address this issue, as are numerous Plasma-based projects. An example of the latter is OmiseGo, who are building — amongst other things — a Plasma DEX that will initially use where Plasma child chains cannot be built, such as Bitcoin. Polkadot clearinghouses for assets Scalability is vital for the widespread adoption of public blockchains and the Plasma framework is a major development towards Ethereum 2.0. Additional sources/Further reading https://plasma.io/ https://ethresear.ch/ https://www.learnplasma.org I’ll be writing a collection of pieces about the development of numerous blockchains and the industry as a whole, covering a range of topics including, but not limited to: sharding and beacon chains, PoS and Casper/Tendermint, interoperability of blockchains and Polkadot, oracles, non-fungible tokens, stablecoins, decentralised exchanges and Plasma’s numerous implementations and security features.

An introduction to Plasma

The de facto business idea that will lead the Web 3.0 revolution is tokenisation. Just when the world thought is the new big thing, the bomb of exploded. People had barely started to understand blockchain and in the background a new paradigm shift was already brewing. blockchain “ tokenisation on blockchain” I kid you not; tokenisation on blockchain is hotter than vanilla-blockchain itself. Source: https://mashable.com/2013/07/09/excitement-gifs/ Forethoughts The rationale behind tokenisation coincides with the rationale behind blockchain. The essence of blockchain lies in the idea of decentralising everything: Power, Money, Value. What if someone tells you that you can own a part of the Taj Mahal or the Moon or (to be extremely far-fetched) Saturn? The idea sounds radical, doesn’t it? If you do happen to own a part of any of the above mentioned objects, the power of the current owners (government, or God…) will dissolve. In actuality, the one who owns more part will have more say. This will breakdown all the enterprise empires and common man will gain and flourish. This will give rise to a whole new economy in the universe — . This economy will not be limited by governments, neither controlled by any set rules by bureaucrats, there won’t be any boundaries on land. Concept of countries and citizenship will fade away. All institutions set up by middlemen will diminish. Everything will be autonomous. Everything will be one. The Token Economy With that being said; EVERYTHING can be tokenised — Your car, your house, free-storage on your computer etc. Tokenisation in Simple Terms Imagine that you own a hard disk with 2TB (1 TB = 1024 GB) storage but about 70% of it remains unused for most of the time. So, your friend tells you that there is an app which gets you money if you offer people your unused storage. This means, people can use your unused disk space and in return of that service they will pay you. The unused part of the disk is divided into smaller parts so that each part can be put up on the “storage market” for people to buy. This is essentially what is tokenisation. Similarly, anything (assets) can be broken down into divisible bits and sold by their parts — essentially known as, tokenised. How to do it? There are platforms like Ethereum, BigchainDB on which this can be implemented. In this article, I’ll show you how to do it on BigchainDB. Step 1: Install BigchainDB driver npm i bigchaindb-driver Step 2: Connect to BigchainDB node const BigchainDB = require('bigchaindb-driver')const API_PATH = 'https://test.bigchaindb.com/api/v1/'const conn = new BigchainDB.Connection(API_PATH, {    app_id: 'Get one from testnet.bigchaindb.com',    app_key: 'Get one from testnet.bigchaindb.com'}) The code snippet below illustrates how to create a divisible asset with 100,000 tokens associated to it. const nTokens = 100000let tokensLeftconst tokenCreator = new BigchainDB.Ed25519Keypair(bip39.mnemonicToSeed('seedPhrase').slice(0,32))function tokenLaunch() {    // Construct a transaction payload    const tx = BigchainDB.Transaction.makeCreateTransaction({            token: 'TT (Tutorial Tokens)',            number_tokens: nTokens        },        // Metadata field, contains information about the transaction itself        // (can be `null` if not needed)        {            datetime: new Date().toString()        },        // Output: Divisible asset, include nTokens as parameter        [BigchainDB.Transaction.makeOutput(BigchainDB.Transaction          .makeEd25519Condition(tokenCreator.publicKey), nTokens.toString())],        tokenCreator.publicKey    )    // Sign the transaction with the private key of the token creator    const txSigned = BigchainDB.Transaction      .signTransaction(tx, tokenCreator.privateKey)    // Send the transaction off to BigchainDB    conn.postTransactionCommit(txSigned)        .then(res => {            tokensLeft = nTokens            document.body.innerHTML ='<h3>Transaction created</h3>';            // txSigned.id corresponds to the asset id of the tokens            document.body.innerHTML +=txSigned.id        })} Now that the tokens have been minted, you can start distributing them to the owners. Tokens can be transferred to an unlimited number of participants. In this example, you are now going to make a transfer transaction to transfer 500 tokens to a new user called Bill. For that, you first need to create a new user and then do the transfer. The code below shows that. const amountToSend = 500const newUser = new BigchainDB    .Ed25519Keypair(bip39.mnemonicToSeed('newUserseedPhrase')        .slice(0, 32))function transferTokens() {    // User who will receive the 500 tokens    const newUser = new BigchainDB.Ed25519Keypair()    // Search outputs of the transactions belonging the token creator    // False argument to retrieve unspent outputs    conn.listOutputs(tokenCreator.publicKey, 'false')        .then((txs) => {            // Just one transaction available with outputs not being spent by            // tokenCreator. Therefore, txs[0]            return conn.getTransaction(txs[0].transaction_id)        })        .then((txOutputs) => {            // Create transfer transaction            const createTranfer = BigchainDB.Transaction                .makeTransferTransaction(                    [{                        tx: txOutputs,                        output_index: 0                    }],                    // Transaction output: Two outputs, because the whole input                    // must be spent                    [BigchainDB.Transaction.makeOutput(                            BigchainDB.Transaction                            .makeEd25519Condition(tokenCreator.publicKey),                            (tokensLeft - amountToSend).toString()),                        BigchainDB.Transaction.makeOutput(                            BigchainDB.Transaction                            .makeEd25519Condition(newUser.publicKey),                            amountToSend)                    ],                    // Metadata (optional)                    {                        transfer_to: 'bill',                        tokens_left: tokensLeft                    }                )            // Sign the transaction with the tokenCreator key            const signedTransfer = BigchainDB.Transaction                .signTransaction(createTranfer, tokenCreator.privateKey)            return conn.postTransactionCommit(signedTransfer)        })        .then(res => {            // Update tokensLeft            tokensLeft -= amountToSend            document.body.innerHTML += '<h3>Transfer transaction created</h3>'            document.body.innerHTML += res.id        })} The official guide can be found . here Some great resources to read from: https://blog.bigchaindb.com/tokenize-the-enterprise-23d51bafb536 https://masterthecrypto.com/tokenization-tokens-create-liquid-world/ https://medium.com/prysmeconomics/the-economics-of-tokenization-part-i-not-everything-can-or-should-be-tokenized-ed9b32f5a0f2 If you have anything else to add, please feel free to mention in the comments below. I’d love to know your thoughts. Thank you very much!

What’s Hotter than the Blockchain Itself? Tokenisation?

It is easy to become jaded with the term “ .” Although the turbulent nature of blockchain ICOs may have added credibility to the claims of skeptics, skepticism can be healthy when new disruptive technology emerges. In fact, skepticism is likely a form of fuel for emerging technologies. As the of any new begins the descent into the Trough of Disillusionment, it is the feedback from skeptics that will refine the tech. blockchain Hype Cycle technology So here begs the question — are there any blockchain projects that could serve practical IoT use cases today? Not considering cryptocurrency investing or ; are there decentralized networks being created right now that could become the preferred architecture for IoT data transport within the next 12 to 18 months? virtual crypto kittens Below is a comparison of the most promising decentralized networks for IoT that can be used or are accepting alpha/beta testers today. A Typical IoT Solution One of the most commonly used protocols for transmitting IoT device data is , a server/client message queue that operates on a publish and subscribe model. MQTT requires a central authority called a Broker to act as the single source of truth. MQTT The premise of MQTT is simple. The architecture has a central Broker receive data from multiple data Publishers. Once data is centrally collected the Broker proceeds to pass the data to any number of Subscribers who are waiting. In addition to being a message queue, an MQTT Broker can support authentication, up to 3 levels of QoS (Quality of Service), and filter data by topics. MQTT was authored originally in 1999 and actively developed by IBM until open-sourced in 2013. Today there are many accepted and for anything you can imagine. MQTT Broker projects MQTT Client libraries A number of commercial IoT platforms use MQTT as a backbone. Because of its versatility companies can have a large number of IoT devices continually publishing data and on the other side, any number of servers subscribing to pre-filtered raw data. In case you are curious, here are the most common MQTT platforms our customers use: , , , , and . AWS IoT Google Cloud IoT Core Azure IoT Hub Losant Adafruit IO MQTT is a great solution, but scaling to a would require massive infrastructure and cloud computing. Any team planning a start-up or commercial project with IoT elements must be ready to incur substantial cloud infrastructure fees and investment in devops**.** hypothetical 20.4 billion IoT devices For this article, MQTT will serve as our baseline to compare Blockchain and Distributed Ledger technologies. Defining Blockchain A Blockchain is an immutable decentralized ledger. You can think of it as a new type of database. The essential core function of a blockchain is a shared ledger that gets updated across the entire network of nodes. Every Node is a computer who will receive and verify copies of the ledger. Data is stored chronologically on this ledger with new data being appended and propagated to the entire network. The data a ledger holds can a record of transactions, documents, files, or something else of value. The Block part of the term refers to the current place in the chain. Once the network confirms a Block copies are sent to all the nodes, becoming a permanent part of this distributed ledger, or database. A new Block is appended after the previous Block. As a result, each Block contains a copy of the previous Block. Blockchain — a chain of blocks! hashed Because each subsequent block contains a hash of the previous block if someone attempts to change data at any point in the chain the resulting would be different and not validated by other nodes. It becomes practically impossible to introduce manipulated data to the network. To make a viable attempt to change the chain would require access to every copy of the ledger around the world and the ability to alter it simultaneously. No person or group will ever have access to that much power making blockchain a trusted source of transactions or identity without the need for a central source. hash A self-validating massively distributed database made up of secure user accounts, and their transactions have some serious appeal. Historically, this problem was impossible to solve and why we created federally insured banks. Ethereum Blockchain for IoT Bitcoin may have introduced blockchain technology to the mainstream, but became the most practical by introducing blockchain to developers. Ethereum allows developers to create their own decentralized contract where they specify the rules, functionality, and even a unique coin. Ethereum Remember the explosion of ICOs in 2017? Ethereum’s tools gave tech entrepreneurs the ability to create those unique cryptocurrencies. The ease at which a developer could create a unique cryptocurrency is a testament to the Ethereum ecosystem, Ethereum’s developer community, and the Ethereum Blockchain. The computing power and storage requirements of traditional blockchains such as Bitcoin and Ethereum have eliminated the possibility of IoT devices being able to use this technology. For example, typical Ethereum nodes use GPUs to process blocks as CPUs are too slow and each node stores nearly 1TB of historic blockchain transactions. As Ethereum stands today, it is slow, expensive, and energy inefficient when compared to centralized cloud services. To become a viable data transport option consensus time and mining fees need to decrease significantly. These issues have not gone ignored by Ethereum’s leadership team. For years core developers have been working on a project called Casper. Casper would move blockchain consensus from a computationally intensive operation called Proof-of-Work to a risk-based operation called Proof-of-Stake. Casper will have significant effects on the Etereum market. For IoT projects, the result will be positive as it will reduce transaction processing costs and allow computationally constrained devices to confirm blocks. In May, the Casper team . released version 0.1.0 and seven days later version 0.2.0 In January, the Ethereum Foundation further recognized scaling issues by announcing two where developers could receive grants ranging from $50,000 to $1,000,000 or more to work on proposed solutions. Specifically, the foundation outlined two strategies they wanted the community to work on in parallel — Blockchain Sharding and Layer-2 Protocols. subsidy programs Sharding will allow Ethereum’s network of nodes to work on multiple blocks simultaneously. In essence, this is similar to how MongoDB shards data into different partitions. The only project we found working on Sharding is . For IoT devices, Sharding is another way Ethereum plans to decrease the time to consensus drastically. prysmaticlabs.com Layer-2 Protocols are commonly defined as sidechains. Borrowing many features from Ethereum, these sidechains create an independent chain where many data transactions can happen off of the Ethereum chain. Eventually, a sidechain will memorialize all of their transactions on to the main Ethereum Blockchain. By creating a sidechain specifically for IoT constrained devices we begin to see a similar architecture to MQTT. Sidechain data flow would be Device → Sidechain → Blockchain where MQTT data flow is Client → Broker → Central Database. Using this architecture there can be a sidechain “Broker” interacting with constrained devices. On the other end the sidechain syncs “side” transactions at set intervals with the main Ethereum Chain. Two notable sidechain projects actively being developed are and . Raiden Plasma With so many Ethereum-based projects and developers focused the issue of scale, Ethereum paired with a sidechain may soon become a popular alternative to traditional Message Queue + Database architectures. IPFS for IoT An exciting and presently practical implementation of Distributed Ledger Technology is the . IPFS creates a distributed file system across independent nodes. IPFS can be used to host websites, files, and even videos. Interplanetary File System (IPFS) IPFS nodes store only the content they’re interested in as well as an index of who is storing what. This is unlike traditional blockchains that require each node to have the entire history of transactions stored locally. IPFS may be very different from conventional blockchains, but similar in that cryptographic hashes of files save across multiple nodes in a network. The is the bold suggestion that the entire public web itself would better serve the world if it used IPFS rather than centralized HTTP servers. Each client node has access to the whole network of files if you know the hash address. Client nodes can decide to store the hash and in doing so becomes a host node of that data. If any nodes storing the data is disconnected, the file continues to be available through the other nodes as if nothing happened. claim to fame for IPFS In addition to the storage tools it exposes to application developers, IPFS also exposes a pub/sub event bus similar to MQTT. Unlike MQTT there is no centralized Broker, IPFS provides a completely decentralized and distributed Broker equivalent. This means that every subscriber interested in an event also acts collectively to Broker event syndication to other interested subscribers. Then, there is also the added benefit of built-in cryptographic security. , but you’d quickly run into the reality that IPFS requires nodes to opt-in to host individual data. For this reason, larger projects built on top of IPFS provide value by bringing structure, libraries, and a “network” of interested nodes all running the same project application. You can use IPFS Pub/Sub today One project built upon IPFS is . The founder, , wrote a blog post that demoed an IoT pub/sub example using an Arduino last year — . The term supercomputer might raise your eyebrow but consider this demo where Computes demos a brute force password attack using multiple computers acting like one. Computes.io Chris Matthieu Build an IoT Supercomputer IPFS gives us the ability to network a series of IoT devices and have them act as a shared file system, an event bus, and with Computes.io as a distributed computation platform. The Helium Distributed Machine Network for IoT is another startup that has caught our attention here at Hologram. They’re building a which is a new term they’re using to describe their product_._ Helium’s network combines a physical blockchain, wireless technology, and open-source software to create a distributed blockchain uniquely built for IoT. Helium Decentralized Machine Network, When Helium first announced the their website stated: “IoT has failed.” Their reasoning was due to the mess of protocols and proprietary technologies, IoT had not lived up to the hype. Decentralized Machine Network The solution they’re developing involves a gateway and low power wireless modules using a new wireless protocol called WHIP. On top of that they’ve created an incentive platform for individuals to act as hotspot providers. The idea is that if you set up a gateway and provide internet access to IoT devices, then you’ll earn cryptocurrency. Helium has also developed novel cryptographic proofs for its proposed network to incentivize expansion and maintenance of the network. Instead of Gateways providing compute cycles and electricity to some power-hungry mining function, Helium Gateways offer the practical service of extending their network to a specific geographic area, as verified by Helium’s Proof of Coverage proof. The end result is that the Gateway receives tokens as a reward for making verifiable contributions to the underlying network. Let’s step through how data transfers over the Helium network. IoT machines will use the WHIP protocol to connect to multiple local Gateways within range securely. Once joined a device sends encrypted data to all the Gateways. Each Gateway adds the data to a block later appending the block to Helium’s global Blockchain. Data objects will contain information about a Router to forward sensor data. The Gateway sends earmarked data to the specific Router. For providing this data transfer service, the Gateway expects payment from the Router. The Router decrypts the data completing the process. This explanation may seem cumbersome as Helium is currently under development. We anticipate better terminology describing this process. “We use a blockchain to reward anyone who deploys a Helium Gateway; a wireless hotspot for machines. This approach enables us to build a community-owned, decentralized network that provides secure, affordable, and ubiquitous wireless coverage that will connect billions of machines to the internet.” – Helium IOTA Tangle for IoT Another technology that is available today is . This project introduces its concept of a Tangle network, rather than a network powered by traditional blockchain. Tangle is a new form of distributed ledger technology, crafted with the Internet of Things in mind. IOTA Source: http://www.iotasupport.com/ Unlike blockchain, a tangle is merely a tangled network of users instead of miner nodes. The idea is that, for any device or user that makes a transaction, it must also process the next two transactions. This scheme allows for fast transactions with fees less than any of the other options discussed. IoT devices can quickly make small transactions for sensor data or functionality. It enables a whole new kind of economy around connected devices. A fun claim of IOTA is safeguarding against quantum computing-based attacks. This claim is impossible to verify but fun to consider. IOTA’s runs through the math. They use which decreases the effectiveness of certain quantum attacks by 1 million. white paper “exclusively quantum resistant cryptographic algorithms” In a future where much of city infrastructure could be managed and influenced by sensor networks and distributed actuators, it is conceivable that an attack involving the spoofing of identity or falsifying of data could be catastrophic. A quantum-resistant cryptographically-secure IoT network would help prevent such attacks over the duration of the node life cycle. Consider the Future While it is still important to hold skepticism, there is a lot more going on with this technology once you look past it as just a means to build a currency When thinking of the billions of devices that will be coming online in the next 5-years, it is easy to see why projects like IPFS and Helium are so important. When we get to the critical threshold of connected devices, we will need the peace of mind to know that they can remain connected. The various protocols under development for distributed networks are solving real problems preventing adoption. We are starting to rethink the internet as less cloud-centralized and more as a decentralized web of devices similar to its roots. It is fun to envision a future where device connectivity happens through micro-transactions via independently owned gateways, and where the network distributes across multiple privately owned nodes. Every device works to maintain the system they consume, a system that can also be forked and merged if parts of it need to go “off-grid.” Final Thoughts Current IoT solutions depend upon platforms that may not exist in a few years’ time. I have built many projects that no longer run because the services used were shut down. The distributed projects shared in this article enable us to go beyond the limitations of central authorities. Systems not easily destroyed and data not easily lost. An important thing to consider is the practical technical solutions behind cryptocurrencies instead of just the financial value. Ultimately, we all will be affected in some way by decentralized technology. In our lifetime we will see at least a few blockchain based systems become part of daily life. It is interesting to witness security and privacy issues make daily headlines; and, as a result, companies find solutions in blockchain technology. As the shift to decentralize happens we see practical use cases start to emerge. What are some areas or industries that you think blockchain or blockchain inspired technology would be good for? Reach out to us on Twitter @Hologram Originally published at hologram.io .

IoT Platforms Should Be Planning Blockchain Integrations

Art by Gal Yosef There is a saying: ”Money rules the world.” I believe it’s not the money itself but the decision-makers possessing it. Money has always been associated with accessible to a narrow swath of society. Power, Influence, Creative Self-Expression, and Unique Opportunities From the psychological perspective, it’s all about the feeling of , which roots in the natural human desire to be Unique and to be an Individual. To live life in your own way. To build the world that you choose. Exclusivity Why do we appreciate exclusivity? Ownership of items from luxury brands and unique art pieces supercharges our feeling of and . exclusivity individuality It inspires us to be creators ourselves - and there is nothing wrong with this desire. It’s a natural call for evolution and personal growth. In fact, there are a few people who are ready to take the responsibility of being creators and driving change in this world. Beginning from childhood, we wanted to be particular, to get recognition for our talents, and to be praised by adults. These instincts stay with us in adulthood, acquiring slightly different forms yet retaining the same meaning. There is nothing wrong with accepting yourself as a kid that wants to be creative and express himself via playing the game. We have never seen luxury brands in this way There are things you can’t buy, including a unique vision of the world and the ability to express it creatively. I had a chance to get acquainted with the self-taught prodigy who is becoming one the most influential digital artists of our time - Gal Yosef. His of luxury brands through vintage cartoon aesthetics has already attracted collaborations with celebrities like , , and rapper A Boogie Wit Da Hoodie. extraordinary artistic vision Justin Bieber Steve Aoki His art implies the , as well as the adult’s desire for ownership of luxurious items. Gal Yosef gives a second life to our favorite cartoon characters. In his art, they acquire the freedom of self-expression through wearing luxury clothing and accessories that fit their temper. honest acceptance of the kid in each adult World leaders in luxury fashion, sportswear, and sports cars, such as Dior, Nike, and Porsche have already partnered with Gal to develop a new look for their visual marketing. "Goofy" by Gal Yosef What if Disney characters were living an ultra-luxury life? What would vintage cartoon characters look like living a modern life? What if it was a wealthy life? Donald Duck, Goofy, Pink Panther, Snoopy, and others appear to us in dramatic lighting, wearing world-class brands like Louis Vuitton, Prada, Gucci, Hermes, and Dior. Each detail of their images speaks about class, exclusivity, and power. They are extravagant, brave, and free to live their life in a new way. Their lifestyle is no longer limited by Disney’s or Pixar’s storyline. Will probably Mickey Mouse want to drive Aston Martin? Or will Popeye the Sailor Man be once seen at a superyacht near the coast of Italy? Bugs Bunny is no longer fun and lovely. He is a powerful King of Carrots, surrounded by luxury. "King of Carrots. Gold Edition" by Gal Yosef via Instagram What if Hello Kitty was always dreaming about purchasing a luxury bag from Dior? "Hello Kitty" by Gal Yosef via Instagram What are Tweety’s plans for Friday’s luxury shopping? Will it be Birkin, Rolex or Audemars Piguet? "These days’ Tweety" by Gal Yosef Luxury brands can find a fresh marketing perspective in awakening the memories of customers’ childhood and nostalgia for the old good times. The aesthetics of vintage cartoons combined with the own incredible style of these can become an explosive mix. brands marketing It’s not the money that is responsible for your happiness, but you as a personality. However, seeing our then-time heroes enjoying their new luxurious life gives some sense of happiness, aesthetic satisfaction, sweet nostalgia, and definitely inspires us to take a fresh look at our own life. I appreciate the opportunity to hear the vision of Gal Yosef who is currently exhibiting his artworks at Eden Gallery - an international high-end art gallery with locations in New York, London, Miami, Mykonos, and Dubai. Disclaimer: All views in this article are my own and don’t imply sponsored endorsement. The use of all images is approved by the creator.

Ultra-Luxury Brands Through the Prism of Gal Yosef’s Cartoon Aesthetics

গ্যাল ইয়োসেফের কার্টুন নন্দনতত্ত্বের প্রিজমের মাধ্যমে আল্ট্রা-লাক্সারি ব্র্যান্ডগুলি

Ultra-Luxusmarken durch das Prisma der Cartoon-Ästhetik von Gal Yosef

Marcas de ultralujo a través del prisma de la estética de dibujos animados de Gal Yosef

Les marques ultra-luxe à travers le prisme de l'esthétique du dessin animé de Gal Yosef

गैल योसेफ के कार्टून एस्थेटिक्स के प्रिज्म के माध्यम से अल्ट्रा-लक्जरी ब्रांड्स

ガル・ヨセフの漫画美学のプリズムを通して見る超高級ブランド

갈 요세프의 만화 미학의 프리즘을 통해 본 초호화 브랜드

Marcas ultra luxuosas através do prisma da estética cartoon de Gal Yosef

Gal Yosef'in Karikatür Estetiği Prizmasından Ultra Lüks Markalar

Các thương hiệu siêu sang qua lăng kính thẩm mỹ hoạt hình của Gal Yosef

从 Gal Yosef 的卡通美学角度看超豪华品牌

In this article, we show how to dockerize a NestJS + Prisma application. We go beyond the basics, following the best practices from and . Our final looks like this: Dockerfiles Snyk Dockerfile FROM node:18 as build
WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
RUN npm install
COPY . .
RUN npx prisma generate
RUN npm run build

FROM node:18-slim
RUN apt update && apt install libssl-dev dumb-init -y --no-install-recommends
WORKDIR /usr/src/app
COPY --chown=node:node --from=build /usr/src/app/dist ./dist
COPY --chown=node:node --from=build /usr/src/app/.env .env
COPY --chown=node:node --from=build /usr/src/app/package.json .
COPY --chown=node:node --from=build /usr/src/app/package-lock.json .
RUN npm install --omit=dev
COPY --chown=node:node --from=build /usr/src/app/node_modules/.prisma/client  ./node_modules/.prisma/client

ENV NODE_ENV production
EXPOSE 3000
CMD ["dumb-init", "node", "dist/src/main"] Now, let's start from the basics and improve our Dockerfile. 1. Basic Dockerfile The simple, starting, dockerfile that we can create is from the following: FROM node                           # Use basic node image
WORKDIR /usr/src/app                # Set working dir inside base docker image
COPY . .                            # Copy our project files to docker image
RUN npm install                     # Install project dependencies
RUN npx prisma generate             # Generate Prisma client files
RUN yarn build                      # Build our nestjs
EXPOSE 3000                         # Espose our app port for incoming requests
CMD ["npm", "run","start:prod"]     # Run our app The previous Dockerfile would generate a valid image and no problems. It will use the latest node image (Node v18 at the time of writing) and run our app. 2. Adding .dockerignore to our project We want to be sure that we aren't leaking any sensitive files to our docker image. In particular, during the command . If we are running this from a CI pipeline, that has just downloaded the repository. Hopefully, we are being careful and there isn't any credential leaked into git. So, no consequences to our docker image. COPY . . But, during installation, we could have some more complex workflows and generate some sensitive files. Either that, or we build our image locally to share or test it. Best to be sure we have a file preventing that. .dockerignore It could have something like this: .dockerignore   # Ignore the ignore
node_modules    # Ignore local node_modules folder
npm-debug.log   # Debug files
Dockerfile      # The dockerfile
.git            # The git history
.gitignore      #
.npmrc          # If accessing a private npm repository here will be the token used, so ignore to prevent leaking
.env-*          # Any other environment that we don't want to include
.gitlab-*       # Deploying with gitlab ?
.github         # Using github actions ?
*.md            # Any 3 Creating a multi-stage image Optimizing our image, we can benefit from using a multistage docker image, reducing image size (which cost us money in some environments like , and also saves us bandwidth and time during deployment). AWS ECR We can install our packages and build the application in one step. Then use another image, copy the generated build files, and install only the production dependencies. For the build step, we could continue with the base node image used so far. We ideally want to use the same version of tooling during all steps, the same node version, underlying OS, and packages. We could go on listing all details using a specific image tag like or not use any specific tag, which will use by default, as we did on the first Dockerfile presented. 14.21.2-buster latest I would recommend, at least, specifying the major node version that you are using, which would give us an image that we know it's mainly compatible with our local environment, but also will be using the most up-to-date official image, reducing the vulnerabilities and bugs that are constantly being found. So far we could change the first steps of our Dockerfile: FROM node:18 as build       # Naming our image to be use in later steps

WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
RUN npm install
COPY . .
RUN npx prisma generate
RUN npm run build In the next step, to reduce our final image size, we would like to use a reduced base image like or (Although has a smaller size, it's not built with , and some tools might not work as expected, watch out). What can happen ( and does in our case using Prisma) is that this smaller doesn't contain some libraries or tools needed from our app. In this case, we need to add . slim alpine alpine libc slim libssl-dev We should also set de variable to , so that different modules work accordingly, reducing the load of debug symbols and logs. NODE_ENV production FROM node:18-slim                                                                           # Base smaller node image
RUN apt update && apt install libssl-dev -y --no-install-recommends                         # Add missing dependency needed for prisma
WORKDIR /usr/src/app
COPY --from=build /usr/src/app/dist ./dist                                                  # Copy de dist folder generated in the previous step
COPY --from=build /usr/src/app/.env .env                                                    # Copy env variables to use
COPY --from=build /usr/src/app/package.json .
COPY --from=build /usr/src/app/package-lock.json .
RUN npm install --omit=dev                                                                  # Install without  dev dependencies to save some space
COPY --from=build /usr/src/app/node_modules/.prisma/client  ./node_modules/.prisma/client   # Copy generated prisma client from previous step
ENV NODE_ENV production
EXPOSE 3000
CMD ["npm", "run","start:prod"] With these two steps, we are going to save around 300 mb only for the different base images. Quick note, in older versions, use npm npm install --production 4 Better App Start There are some caveats running directly our app through . First, npm doesn't forward any signal to the spawned process, and our process would be assigned PID 1 which is treated differently by the kernel of our docker image. This can affect the ability to gracefully shut down our app and, cause difficult-to-debug problems. npm See the references at the end for more info. So, let's change our command with: RUN CMD ["dumb-init", "node", "dist/src/main"] 5 Security We should never want to run our application with the root privileges, and although the current images of node run with a low privilege user by default, all the files that we copied are owned by root. node In some cloud environments like AWS or Azure, this could have little to null consequences, it's better not to risk it. So, in every copy, we would downgrade to the same user. We could then add the argument to all our commands. node --chown=node:node COPY Putting it all together we get the that we introduced at the beginning: Dockerfile FROM node:18 as build
WORKDIR /usr/src/app
COPY package.json .
COPY package-lock.json .
RUN npm install
COPY . .
RUN npx prisma generate
RUN npm run build

FROM node:18-slim
RUN apt update && apt install libssl-dev dumb-init -y --no-install-recommends
WORKDIR /usr/src/app
COPY --chown=node:node --from=build /usr/src/app/dist ./dist
COPY --chown=node:node --from=build /usr/src/app/.env .env
COPY --chown=node:node --from=build /usr/src/app/package.json .
COPY --chown=node:node --from=build /usr/src/app/package-lock.json .
RUN npm install --omit=dev
COPY --chown=node:node --from=build /usr/src/app/node_modules/.prisma/client  ./node_modules/.prisma/client

ENV NODE_ENV production
EXPOSE 3000
CMD ["dumb-init", "node", "dist/src/main"] If you want to go more in-depth I recommend you the following articles: Snyk: 10 best practices to containerize Node.js web applications with Docker Docker: Best practices for writing Dockerfiles Sysdig: Top 20 Dockerfile best practices Yelp: Introducing dumb-init, an init system for Docker containers

5 Steps for Dockerizing NestJs With Prisma

Today we're happy to announce the open source release of WunderBase, a Serverless Database with a GraphQL API on top of SQLite, Firecracker/Fly machines, and Prisma. It's embarrassingly simple, but powerful, as the codebase is less than 400 lines of Go. WunderBase is built on top of Fly machines, which is a REST API that allows you to run virtual machines in seconds. What's special about machines is that they can sleep when an application exits with a zero exit code. When you send a request to WunderBase, the virtual machine wakes up in about 300-500ms and executes the request. Ten seconds (configurable) after the last request was processed, we send the machine to sleep again. This means that you really only pay for storage and the CPU time you really use, hence the name "Serverless Database". If you'd like to jump right into the code and try WunderBase out for yourself, you can find the . source code on GitHub See WunderBase in action https://www.youtube.com/watch?v=W_5iJom0cLU&t=2s Why we've built WunderBase We're in the works of building WunderGraph Cloud, applying the principles of Vercel to Backend/API development. We take the most important backend primitives like Authentication & Authorization, Database, Queue, PubSub, Key-Value Store, Cache, etc. and make them available as a single, unified SDK. Git push and 30 seconds later, you've got a fully functional Serverless backend without touching any infrastructure. Make some code changes, open a PR, and get a preview environment with your changes. For this to work, we need a fast and inexpensive way to create and destroy databases. But as you'll see, there are many other use cases for WunderBase than just preview environments. How does WunderBase work? Here's an overview of how WunderBase works: You deploy WunderBase to a Fly machine with a volume attached The Fly machine boots up and starts WunderBase We use the the file to migrate the database using the Prisma Migration Engine prisma.schema Once the migration is done, we create a lock file to prevent future migrations if the file didn't change prisma.schema Finally, we start the Prisma Query Engine to serve the GraphQL API Ten seconds (configurable) after the last request was processed, we exit WunderBase with a zero exit code to indicate to fly that this Machine should go to sleep Request flow: You send a request to WunderBase The Fly machine wakes up in about 300-500ms The fly proxy forwards the request to WunderBase WunderBase sanitizes the request and proxies it to the Prisma Query Engine The Prisma Query Engine executes the request and returns the result WunderBase sends the result back to the client Again, after ten seconds of inactivity, we shut down the Machine Rethinking Serverless with Fly machines When using AWS Lambda, you have to follow certain rules to make your application compatible with the environment. E.g. when you're using Golang, you have to export a function that takes a and the name of the event. Also, you don't really have much control over the environment your application runs in. At some point, the Lambda runtime will shut down your application. Handler context.Context With Fly machines, we can operate at a much lower level. We create a Docker container that listens on a specific port. We tell fly to run this container and send all requests to this port. If we think the Machine should sleep, we exit the container with a zero exit code. Fly will keep our volume around and start the container again when we send a request. A lot of applications are written in a Serverful single-tenant way would usually be quite expensive to run as a multi-tenant service. With Fly machines, we can run these applications in a very cost-efficient way. However, there's a catch. We have to optimize the application for fast startup and shutdown. I know that fly is working on allowing machines to "sleep" and "resume", just like closing and re-opening a laptop. This would allow us to run applications that are not optimized for fast startup and shutdown. In the meantime, we've built WunderBase in a way to optimize for fast startup and shutdown times. Optimizations to reduce cold start and shutdown times When a request is waiting to be served, we need to make sure that the Machine starts up as fast as possible. At the same time, we always want to keep the database schema in sync with the file. If we ran a migration every time the Machine starts up, we would have to wait for the migration to finish before we can serve the request. That's not ideal, so we've optimized this path. prisma.schema When the Machine starts up, we hash the file and check if there's a lock file with the same hash. If there's a lock file, we compare the content of the lock file with the hash of the file. If they are the same, we know that the migration for this schema has already been executed. If there's no lock file, we run a migration and create a lock file with the hash of the file. prisma.schema prisma.schema prisma.schema We store the lock file in the volume, so it's available even if the Machine was sleeping. Next, we needed to make sure that the Prisma Query Engine shuts down properly. We start the Prisma Query Engine as a separate process. Before we kill the main process, we send a signal to the Prisma Query Engine. If we would immediately kill the main process, the sub-process would keep the Machine from shutting down for a few more seconds. Instead, we're using a to wait for the Prisma Query Engine to shut down before we exit the main process. This way, we've reduced the shutdown time from 5-10 seconds to 1-2 seconds. SIGTERM sync.WaitGroup If we didn't do this, you'd have to wait up to 10 seconds when sending a request to WunderBase while it's shutting down. How does WunderBase compare to other Serverless Databases like DynamoDB, CockroachDB, MongoDB, FaunaDB, Planetscale or Neon? We can have long debates about what Serverless really is or if the term actually makes sense. After all, there are still servers involved. To me, Serverless means that you don't have to worry about the infrastructure and that you only pay for what you really use. For a long time, Serverless was mostly about functions. You write a function, deploy it, and you're done. Someone else takes care of the infrastructure and you only pay per request. Then came a new wave of Serverless offerings that give you a "Serverless Database". You write a schema, deploy it, and you're done. But are these really Serverless? From a user perspective, yes. From a technical perspective, no. Most databases still are "Serverful" in the sense that the database server is always running. Some solutions, like Neon, try to solve this problem by separating the compute and storage layer. Others, like CockroachDB or Mongo put a proxy in front of the database so that you can "imitate" a Serverless Database. In contrast, the storage layer of WunderBase is always "sleeping", because it's just a file. SQLite is probably the only real Serverless database because it's just a file. The Serverful part of WunderBase is the proxy that runs the Prisma Query Engine and translates between GraphQL and SQL. But as we've discussed earlier, we can send this proxy to sleep and wake it up again when we need it. Another important aspect of WunderBase is that it's actually quite simple and very transparent what's going on. We've got a proxy that translates between GraphQL and SQL, and we have a SQLite database / file on a volume. I've told one of my Co-Founders that I'm a bit embarrassed to release WunderBase because it's so simple and just a few hundred lines of code. He answered that it's not embarrassing at all, because it's actually quite impressive that we've managed to build something that's so simple and yet so powerful. And he's right! Sometimes you combine the right ingredients in the right way and achieve something that took others years to build. It took me just a few hours to build WunderBase. The most time-consuming part was to write proper tests and this blog post. What are the use cases for WunderBase? You might be thinking that WunderBase is just a toy project. We're definitely not going to compete with the big players in the Serverless Database space. Instead, we're looking at serving use cases that others are unable to serve. I'll give you a few examples: It takes seconds to create a new WunderBase instance. You can use it for a quick prototype or to test something out. For each branch you deploy, you can have a separate WunderBase instance that's isolated from the main branch/database. A lot of applications don't ever store more than a few gigabytes of data and have very little traffic. WunderBase is perfect for these use cases. One use case that excites me the most is that you can "shard" at the database layer. What this means is that you can have a single database model that's shared across multiple databases. You can have one database per user, tenant, or any other key and route traffic to the correct database based on the user's (tenant's) ID. If you have a customer with a lot of data, you can easily put them on a separate database. If each customer has their own database, you can do point in time recovery for each customer individually. Another interesting use case is OLAP. Let's say we'd like to analyze terabytes of data in seconds. We can shard the data across multiple databases and run a query on each database in parallel. We can then aggregate the results and return them to the user. While we're not serving any requests, we can shut down the databases. This way, we're only really paying for the storage and compute that we're using. This could be an Open Source alternative to BigQuery. How fast is WunderBase? I've done some benchmarking and was able to achieve 2k write requests per second and 10k read requests per second. There's a benchmark script in the WunderBase repository that you can use to run your own benchmarks. Make sure to set the rate limit environment variables properly to not get rate-limited. During my testing I've realized that 2k/10k is the maximum that I can achieve before getting Timeout errors, so I've added some rate limiting to the proxy to keep everything stable. How can you scale WunderBase? There are multiple ways to scale WunderBase. We can add read replicas to scale reads. There's tooling to replicate SQLite databases, both locally or even remotely. So we could have a master database and read replicas in different regions. Another way to scale WunderBase is to have multiple master databases. With this approach, we can scale writes based on a key like the user ID or tenant ID.If you've got users all over the world, you can combine both approaches to optimize for latency. Can you easily migrate from WunderBase to a different database? Another question you might ask is if you're able to migrate from SQLite to e.g. PostgreSQL or MySQL. The answer is yes and it's actually quite easy. As we're using Prisma, we can just change the in the block in the file. If we're using the same Schema, Prisma will give us the same GraphQL API, even if we're using a different database. So it's possible to switch from SQLite to MySQL, PostgreSQL, SQLServer or even Planetscale. provider datasource prisma.schema How can you backup WunderBase? Backups can be implemented e.g. by leveraging LiteStream, a tool that streams the changes from a SQLite database to S3. Caveats There's one caveat that you should be aware of. The GraphQL API that WunderBase (Prisma Query Engine) exposes is not intended to be publicly exposed. You should always put a in front of it. GraphQL API Gateway like WunderGraph It's perfectly fine to use GraphQL as the ORM layer, but this API is not intended to be consumed by clients in the browser directly. Additionally, Prisma Query Engine is only exposing a subset of GraphQL, e.g. you cannot use variable definitions. We've done some extra steps in WunderGraph to make it compatible with GraphQL, like writing a "variable definition inliner" to automatically inline variable definitions and make the GraphQL Operation compatible with the Prisma Engine. I'll follow up with a blog post about this topic as it was actually quite interesting to reverse engineer the Prisma Query Engine and make all of this work together. Thank you Prisma! All of this wouldn't have been possible without the amazing work that the Prisma team has done. Besides the 400 lines of glue code that I've written, the rest is just Prisma. I also know that this is not the intended use case of Prisma. Nikolas Burk keeps reminding me that Prisma is an ORM and the GraphQL layer of the Prisma Query Engine is an internal detail. Prisma generates a client library on top of this Engine which uses GraphQL internally. I personally think that it's much more powerful to expose the GraphQL API directly. This way, I'm able to multiple APIs together easily and talk to all my services with a single language. join So, thank you and sorry for abusing your product! Open Source is awesome! =) The future of Firecracker-based Applications I'm very excited about the future of Firecracker-based applications. I'm pretty sure that this paradigm will allow us to build or re-build a lot of applications in a more efficient way, like Serverless Databases, Serverless Caches, Serverless Queues, Serverless Search Engines, etc. What's next? Our goal for WunderGraph is to create a TypeScript Framework that allows you to build Serverless Applications in a very simple way. From databases to file storage, queues, pub/sub, key-value, and caching. We want to provide a unified SDK that allows you to focus on the code, not on the infrastructure. Today, we're starting with a Database, but there's alot more to come. WunderGraph Cloud Early Access Be amongst the first to try WunderGraph Cloud & WunderBase for free. With WunderGraph Cloud, you'll be able to git push your application and get a fully functional Serverless API alongside your Database in seconds. Join the Waitlist What would you build with WunderBase? Finally, I'd love to hear what you'd build with WunderBase. I've got a few ideas (see above), but I'm sure that there are many more use cases that I haven't thought of yet. In case you've missed it above, here's the link to the . Give it a star if you like the project and go tinkering with it. =) source code of WunderBase on GitHub Also published . here

WunderBase - Serverless GraphQL Database on Top of SQLite, Firecracker and Prisma

Today my plan is to go through Prisma ORM's basic setup and usage and explain what I like about this ORM and what I don't like. I have a lot of experience working with different ORMs and plain queries for relational databases, and I will be reviewing with this background knowledge. I'm going to use TypeScript language and SQLite database, as well as yarn package manager in my examples. I don't expect you to know them, but I'm going to provide a pretty self-explanatory code or some comments. Installing Prisma to a new project For the most part, I'm going to follow official docs Let's start by creating an empty project and initializing it mkdir prisma_orm_review
cd prisma_orm_review
yarn init  -y
yarn add -D typescript ts-node @types/node Adding file tsconfig.json touch tsconfig.json {
  "compilerOptions": {
    "sourceMap": true,
    "outDir": "dist",
    "strict": true,
    "lib": ["esnext"],
    "esModuleInterop": true
  }
} Adding Prisma yarn add prisma Initializing Prisma for MySQL npx prisma init --datasource-provider mysql Data modeling Prisma ORM takes a bit unusual approach to data modeling. You have to define your models in a separate file and use specific to the ORM syntax. It's not a big deal, but it's worth mentioning. The syntax is pretty much self-explanatory. model Account {
  id              Int       @id @default(autoincrement())
  parentAccountId Int?
  parentAccount   Account?  @relation("Parent", fields: [parentAccountId], references: [id])
  childAccounts   Account[] @relation("Parent")
  email           String    @unique
  name            String?
  meta            Json
  isActive        Boolean   @default(false)
  createdAt       DateTime  @default(now())
  posts           Post[]
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
  published Boolean @default(false)
  account   Account @relation(fields: [accountId], references: [id])
  accountId Int
} Based on that schema, Prisma ORM will generate a client to work with the database. Also, it's possible to generate migrations for the database. npx prisma migrate dev --name init Easy Level Queries This script will create an account with one post. It's possible to create a nested structure to create the account and the post simultaneously, which is very lovely. I do recommend enabling query logs in the dev environment. This will help you identify problems with your queries. Also, you can see the queries used under the hood. script.ts import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient({
  log: ["query", "info", "warn", "error"],
});

async function main() {
  // create an account
  const accountWithPost = await prisma.account.create({
    data: {
      email: "hello@exmaple.com",
      name: "John Doe",
      meta: {
        firstName: "John",
        lastName: "Doe",
        age: 30,
      },
      isActive: true,
      posts: {
        create: {
          title: "Post #1",
          content: "Hello world",
          published: true,
        },
      },
    },
  });
  console.log(accountWithPost);

  // select active accounts
  const activeAccounts = await prisma.account.findMany({
    where: {
      isActive: true,
    },
  });
  console.group(activeAccounts);
}

main()
  .then(async () => {
    await prisma.$disconnect();
  })
  .catch(async (e) => {
    console.error(e);
    await prisma.$disconnect();
    process.exit(1);
  }); This case is pretty simple. In the end, we have a couple of SQL queries to create an account and a post and one query to select created account. Also, it wraps everything into one transaction. No surprises here. BEGIN;
INSERT
INTO
    cta.Account (id, email, name, meta, isActive, createdAt)
VALUES
    (?, ?, ?, ?, ?, ?);
INSERT
INTO
    cta.Post (id, title, content, published, accountId)
VALUES
    (?, ?, ?, ?, ?);
SELECT
    cta.Account.id,
    cta.Account.parentAccountId,
    cta.Account.email,
    cta.Account.name,
    cta.Account.meta,
    cta.Account.isActive,
    cta.Account.createdAt
FROM
    cta.Account
WHERE
    cta.Account.id = ?
LIMIT ? OFFSET ?;
COMMIT; Next query will select all active accounts from the database. In our database, we have only one account, so I do not worry about pagination. But in real life, you will have a lot of accounts, so pagination is a must. SELECT
    cta.Account.id,
    cta.Account.parentAccountId,
    cta.Account.email,
    cta.Account.name,
    cta.Account.meta,
    cta.Account.isActive,
    cta.Account.createdAt
FROM
    cta.Account
WHERE
    cta.Account.isActive = ? Raw SQL Queries In the next step, let's select the first 10 distinct account names. async function main() {
  const result = await prisma.account.findMany({
    select: {
      name: true,
    },
    where: {},
    distinct: ["name"],
    take: 10,
    skip: 0,
  });

  console.log(result);
} The code looks pretty simple. But I see a surprise in the logs. The generated query looks like this: SELECT
    cta.Account.id,
    cta.Account.name
FROM
    cta.Account
WHERE
    1 = 1
ORDER BY
    cta.Account.id ASC As you can see, offset and limit are not used. This is because Prisma does not use in the query and filters data in memory. It's not a problem for small databases but for large ones, it's a performance killer. Imagine filtering in memory millions of records just to find the first 10. DISTINCT In this case, we have to jump to the raw SQL query. async function main() {
  const limit = 10;
  const result = await prisma.$queryRaw<Array<{ name: string }>>(
    Prisma.sql`SELECT DISTINCT
                   (name)
               FROM
                   Account
               LIMIT ${limit}`
  );

  console.log(result);
} Generated query: select distinct(name) from Account limit ? At the first glance, it looks like an example from a book called "SQL injections in practice." But it's not. Under the hood, does some magic to generate a query. Prisma.sql The output of this console.log(Prisma.sql`select distinct(name) from Account limit ${limit}`); {
  text: 'select distinct(name) from Account limit $1',
  sql: 'select distinct(name) from Account limit ?',
  values: [ 10 ]
} All variables in the query will be replaced by placeholders. Therefore, it's safe to use variables in the query. Raw SQL Unsafe At this step, let's add more complexity to our previous query by filtering by fields in metadata. To make our life a bit more complex, the names of the fields are not predefined and will be provided from the frontend. async function main() {
  const limit = 10;
  const jsonFieldName = "firstName";
  const jsonFieldValue = "John";

  const result = await prisma.$queryRaw<Array<{ name: string }>>(
    Prisma.sql`SELECT DISTINCT
        (name)
    FROM
        Account
    WHERE
        meta ->> "$.${jsonFieldName}" = ${jsonFieldValue}
    LIMIT ${limit};
`
  );
} Turns out, this query does not work because replace all variables with placeholders. The resulting SQL is: Prisma.sql SELECT DISTINCT
    (name)
FROM
    Account
WHERE
    meta ->> "$.?" = ?
LIMIT ?; And it's time to move to the . We are still going to use query parameters for JSON field values and limit, but JSON field name will be concatenated with the query. $queryRawUnsafe async function main() {
  const limit = 10;
  const jsonFieldName = "firstName";
  const jsonFieldValue = "John";

  const result = await prisma.$queryRawUnsafe<Array<{ name: string }>>(
    `SELECT DISTINCT
        (name)
    FROM
        Account
    WHERE
        meta ->> "$.${jsonFieldName}" = ?
    LIMIT ?;
`,
    jsonFieldValue,
    limit
  );

  console.log(result);
} Resulting query: SELECT DISTINCT
    (name)
FROM
    Account
WHERE
    meta ->> "$.firstName" = ?
LIMIT ?; And this one looks pretty good. I do not recommend using such queries in production. It will be slow. Conclusion In general, Prisma ORM is a good choice for your project. It lacks some features of other ORMs; for example, performing in the memory is not acceptable. But it's not a big deal because you can jump the lower levels such as raw SQL queries. distinct

Stories, News & Mentions about PRYSM

Prysm’s Stories on HackerNoon