diff --git a/docs/bridges/About Token Bridges/hashi-integration.md b/docs/bridges/About Token Bridges/hashi-integration.md new file mode 100644 index 00000000..ae835a33 --- /dev/null +++ b/docs/bridges/About Token Bridges/hashi-integration.md @@ -0,0 +1,116 @@ +--- +sidebar_position: 5 +title: Hashi Integration +description: How do the bridges work after Hashi integration +keywords: [amb bridge, arbitrary message bridge, omnibridge, xdai bridge, hashi] +--- + +# Hashi integration + +The proposal of Hashi integration on Gnosis Chain's bridges (AMB & Omnibridge, xDAI bridge) is [approved by Gnosis DAO members](https://forum.gnosis.io/t/gip-93-should-gnosisdao-support-the-integration-of-hashi-within-gnosis-chains-canonical-bridges/8245/5) on April 2nd, 2024. The integration introduces advanced security measures, mitigates systemic risks, and ensures the Gnosis Chain ecosystem remains resilient against the evolving landscape of security threats. With the efforts from Cross-Chain Alliance and Gnosis team, the integration is going toward production. + +## What’s new? + +1. Hashi Manager contract: New contract. Set reporters, adapters, and threshold parameters used by the bridge contract. +2. New variables/function: + 1. HASHI_ENABLED: New variable. When set to true, every message can be approved by Hashi, but the message need not to be approved by Hashi for it to get executed. + 2. HASHI_MANDATORY: New variable. When set to true, every message has to be approved by Hashi before execution. + 3. isApprovedByHashi(bytes32 msgId): New public function. Return whether a message w.r.t a message Id is approved by Hashi. + 4. setHashiManager(address HashiManager): New function, onlyOwner. Set Hashi Manager contract on the bridge contract. +3. Modified events: + 1. xDAI Bridge: in xDAI bridge, a `bytes32 nonce` is added into `UserRequestForAffirmation` and `UserRequestForSignature` events. + 1. `event UserRequestForAffirmation(address recipient, uint256 value)` is changed to `event UserRequestForAffirmation(address recipient, uint256 value, bytes32 nonce)` + 2. `event UserRequestForSignature(address recipient, uint256 value)` is changed to `UserRequestForSignature(address recipient, uint256 value bytes32 nonce)` + +## AMB & Omnibridge + +![](../../../static/img/bridges/hashi/Hashi-Gnosis-AMB.png) + +For Omnibridge / AMB: + +**Ethereum → Gnosis Chain** + +1. User approves token for Foreign Omnibridge +2. User calls ForeignOmnibridge.relayTokens(address token, address receiver, uint256 amount) + 1. ForeignOmnibridge calls ForeignAMB.requireToPassMessage() + 2. ForeignAMB check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage + 3. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters. + 4. Reporters relay the messageId and message hash to adapter contract on Gnosis Chain. + 5. Light Client based oracle only stores hashes on Gnosis Chain. +3. If Hashi is enabled & mandatory, off chain executor calls Gnosis Chain’s Yaru.executeMessages(), which check if the hash is agreed upon a threshold amount of adapters (set in Hashi Manager contract) adapters and set isApprovedByHashi(messageId) to true eventually. +4. Bridge validators detects UserRequestForAffirmation event and call HomeAMB.executeAffirmation. If Hashi is enabled & mandatory, this step has to wait after step 3. + +**Gnosis Chain → Ethereum** + +1. User approves token for Home Omnibridge +2. User calls HomeOmnibridge.relayTokens(address token, address receiver, uint256 amount) + 1. HomeOmnibridge calls HomeAMB.requireToPassMessage() + 2. HomeAMB check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage + 3. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters. + 4. Reporters relay the messageId and message hash to adapter contract on Ethereum. +3. Bridge validators detects UserRequestForSignature event and call HomeAMB.submitSignatures. +4. If Hashi is enabled & mandatory, off chain executor calls Ethereum’s Yaru.executeMessages(), which check if the hash is agreed upon adapters and set isApprovedByHashi(messageId) to true eventually. +5. User claims token by calling Ethereum’s ForeignAMB.executeSignatures(). + +## xDAI briddge + +![](../../../static/img/bridges/hashi/Hashi-Gnosis-AMB.png) + +**Ethereum → Gnosis Chain** + +1. User approves token for Foreign xDAI bridge. +2. User calls ForeignXDAIBridge.relayTokens(address receiver, uint256 amount) + 1. ForeignXDAIBridge check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage + 2. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters. + 3. Reporters relay the messageId and message hash to adapter contract on Gnosis Chain. + 4. Light Client based oracle only stores hashes on Gnosis Chain. +3. If Hashi is enabled & mandatory, off chain executor calls Gnosis Chain’s Yaru.executeMessages(), which check if the hash is agreed upon a threshold amount of adapters (set in Hashi Manager contract) and set isApprovedByHashi(messageId) to true eventually. +4. Bridge validators detects UserRequestForAffirmation event and call HomexDAIBridge.executeAffirmation. If Hashi is enabled & mandatory, this step has to wait after step 3. Block Reward contract emits AddedReceiver event, which will mint equivalent amount of xDAI to receiver in the next block. + +**Gnosis Chain → Ethereum** + +1. User calls HomexDAIBridge.relayTokens(address receiver, uint256 amount) or transfer xDAI to HomexDAIBridge without msg.data. + 1. HomexDAIBridge check if HASHI_IS_ENABLED is true, and call Yaho.dispatchMessage + 2. Off chain relayer detects MessageDispatched event from Yaho and call Yaho.relayMessagesToAdapters to relay message to each reporters. + 3. Reporters relay the messageId and message hash to adapter contract on Ethereum. +2. Bridge validators detects UserRequestForSignature event and call HomexDAIBridge.submitSignatures. +3. If Hashi is enabled & mandatory, off chain executor calls Ethereum’s Yaru.executeMessages(), which check if the hash is agreed upon adapters and set isApprovedByHashi(messageId) to true eventually. +4. User claims token by calling Ethereum’s ForeignxDAIBridge.executeSignatures(). DAI is transfer to the receiver eventually. + +# Testnet environment + +For testing purpose, we've set up testnet environemnt. Users are welcome to experiment with the testnet environments: + +- Sepolia addresses + 1. ForeignAMB: [0x2F62433e00168af10c70bc39e2fDbEe5DaCA257b](https://sepolia.etherscan.io/address/0x2F62433e00168af10c70bc39e2fDbEe5DaCA257b) + 2. Hashi Manager: [0x6C5F4F8a719bF054D6b08E3cCc27a5f208Ec8766](https://sepolia.etherscan.io/address/0x6C5F4F8a719bF054D6b08E3cCc27a5f208Ec8766#writeProxyContract) +- Chiado addresses + 1. Home AMB: [0xAF18353BF369897Aab18ec225422F921be9F7eC6](https://gnosis-chiado.blockscout.com/address/0xAF18353BF369897Aab18ec225422F921be9F7eC6?tab=contract) + 2. Hashi Manager: [0xe505cD6522E9A1c2309a915f83dDCA9addaC0895](https://gnosis-chiado.blockscout.com/address/0xe505cD6522E9A1c2309a915f83dDCA9addaC0895?tab=contract_code) + 3. AMB BridgeHelper: [0x3fba3D7Ae204a684E4359A3fC211C18EA155cd78](https://gnosis-chiado.blockscout.com/address/0x3fba3D7Ae204a684E4359A3fC211C18EA155cd78) + +## Omnibridge + +- Sepolia address + 1. Foreign Omnibridge: [0xc4e06E44B2d1e148beFAa3cB2012A985EFe7032a](https://sepolia.etherscan.io/address/0xc4e06E44B2d1e148beFAa3cB2012A985EFe7032a) + 2. WETH Router: [0x65E64139f202F89cb6b4bFc140bf01Cda1886465](https://sepolia.etherscan.io/address/0x65E64139f202F89cb6b4bFc140bf01Cda1886465#code) +- Chiado address + 1. Home Omnibridge: [0xB866dC5321Ca41a22938A7afD5Bc3c5069975874](https://gnosis-chiado.blockscout.com/address/0xB866dC5321Ca41a22938A7afD5Bc3c5069975874?tab=write_proxy) + +## xDAI + +- Sepolia addresses + 1. Foreign xDAI: [0x97589968FA7ef153af44C6F5d0Fb9AcaEA97AC94](https://sepolia.etherscan.io/address/0x97589968FA7ef153af44C6F5d0Fb9AcaEA97AC94) + 2. Hashi Manager: [0x90d3c0c9BCb317E80A459B0126257665186E59fa](https://sepolia.etherscan.io/address/0x90d3c0c9bcb317e80a459b0126257665186e59fa#code) +- Chiado addresses + 1. Home xDAI: [0x867696eA1cfA243aB909797022D0A0C99BdACcF1](https://gnosis-chiado.blockscout.com/address/0x867696eA1cfA243aB909797022D0A0C99BdACcF1?tab=contract) + 2. Hashi Manager: [0x5b745C021ef62f90862a812EB6763f5758e51eE2](https://gnosis-chiado.blockscout.com/address/0x5b745C021ef62f90862a812EB6763f5758e51eE2?tab=contract) + 3. xDAI Bridge Helper: [0xA7bE47d1111baFDb2f0E9ce8D6431508aC2fd98e](https://gnosis-chiado.blockscout.com/address/0xA7bE47d1111baFDb2f0E9ce8D6431508aC2fd98e#code) + +## Reference + +1. AMB contracts: https://github.com/crosschain-alliance/tokenbridge-contracts/tree/feat/hashi-integration-amb +2. xDAI bridge contracts: https://github.com/crosschain-alliance/tokenbridge-contracts/tree/feat/hashi-integration-xdai-bridge +3. Test: https://github.com/crosschain-alliance/tokenbridge-contracts-migration-tests +4. Audits: https://crosschain-alliance.gitbook.io/hashi/v0.2/audit-report#gnosis-bridge-hashi-integration +5. Hashi: https://crosschain-alliance.gitbook.io/hashi/v0.2/introduction diff --git a/docs/node/Node Tools/eth-docker.md b/docs/node/Node Tools/eth-docker.md index 8ea9a1f4..ff259ed7 100644 --- a/docs/node/Node Tools/eth-docker.md +++ b/docs/node/Node Tools/eth-docker.md @@ -1,18 +1,18 @@ --- -title: eth-docker +title: Eth-docker --- import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -# eth-docker +# Eth-docker -[eth-docker](https://eth-docker.net/) is a docker automation project for Ethereum consensus and execution clients. It aims to make running a Ethereum staking full node simpler than setting everything up manually, while allowing the user choice when it comes to the exact client mix they wish to run. +[Eth-docker](https://eth-docker.net/) is a docker automation project for Ethereum consensus and execution clients. It aims to make running a Ethereum staking full node simpler than setting everything up manually, while allowing the user choice when it comes to the exact client mix they wish to run. -eth-docker allows user to set up Gnosis clients by answering simple dialog-based questions on terminal. +Eth-docker allows user to set up Gnosis clients by answering simple dialog-based questions on terminal. ## References -1. eth-docker Docs: https://eth-docker.net/ +1. Eth-docker Docs: https://eth-docker.net/ 2. Github: https://github.com/eth-educators/eth-docker diff --git a/docs/node/Node Tools/eth-swarm.md b/docs/node/Node Tools/eth-swarm.md new file mode 100644 index 00000000..e69de29b diff --git a/docs/technicalguides/custom-signers/README.md b/docs/technicalguides/custom-signers/README.md new file mode 100644 index 00000000..9df52916 --- /dev/null +++ b/docs/technicalguides/custom-signers/README.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 4 +sidebar_label: Custom Signers +--- + +# Custom Signers + +Custom signers allow developers to inject their own signing mechanisms tailored to specific use cases. This flexibility enhances security, usability, and adaptability in different environments, such as multi-signature wallets or smart contract interactions. + +## Why Use Custom Signers? + +### Tailored Signing Methods +With custom signers, you can personalize the signing process to fit your dApp’s specific needs. This could mean automatic signing for trusted operations, requiring additional confirmation for sensitive actions, or integrating unique hardware devices for enhanced security.Users can now interact with dapps by just using their emails or passkeys. + +### Enhanced Security +Custom signers give developers more control over how and where signing keys are stored. This can include signing transactions in hardware security modules (HSMs), using a multi-sig contract, or requiring multi-factor authentication before a transaction is signed. + +### Optimized for Specific Use Cases +Whether you’re dealing with privacy-focused transactions, or social recovery mechanisms, custom signers can be configured to handle the specific logic needed. They allow for flexibility in crafting unique user flows that require specialized transaction signing methods. + + + + + + + + \ No newline at end of file diff --git a/docs/technicalguides/custom-signers/dynamic.md b/docs/technicalguides/custom-signers/dynamic.md new file mode 100644 index 00000000..439fa7ad --- /dev/null +++ b/docs/technicalguides/custom-signers/dynamic.md @@ -0,0 +1,142 @@ +--- +description: Dynamic offers smart and beautiful login flows for crypto-native users, simple onboarding flows for everyone else, and powerful developer tools that go beyond authentication. +keywords: [dynamic ,custom-signers] +--- + +# Dynamic + +Dynamic offers smart and beautiful login flows for crypto-native users, simple onboarding flows for everyone else, and powerful developer tools that go beyond authentication. This is a basic guide which demonstrates the integration of Dynamic wallet with Gnosis chain and generate offchain user signatures. + +![Dynamic Image](../../../static/img/signers/dynamic.png) + + +## Guide + +- Create a NextJs application from scratch + +``` +npx create-next-app dynamic-gnosis +# install with Tailwind +``` +- Install Dynamic labs SDK & some other dependencies + +``` +npm install @dynamic-labs/ethereum @dynamic-labs/ethers-v6 @dynamic-labs/sdk-react-core +``` + +- Create an account at [Dynamic Web App](https://app.dynamic.xyz/) and choose the Ethereum Sandbox option. +In the dashboard, enable the networks you want to allow your users. For our example we will enable Gnosis network. Also make sure you have Email as an authentication enabled for your users. This helps create a wallet by just using user's email. + +- In the [developers section](https://app.dynamic.xyz/dashboard/developer/api), copy the Environment ID, we will need this in the next step. + +- Initialize the SDK in your **layout.tsx** file like this. The goal is to initialize the SDK as early as possible when loading you application. Put your Environment ID in the proper variable. +Make sure you have **EthersExtension** also added in the extensions variable, this will be useful later! +``` +export default function RootLayout({ + children, +}: { + children: React.ReactNode; +}) { + return ( + + ", + walletConnectors: [EthereumWalletConnectors], + walletConnectorExtensions: [EthersExtension], + }} + > + {children} + + + ); +} + +``` + + +- Create a components folder and inside that create a component **DynamicWidgetButton.tsx** and here we need to declare our DynamicWidget component provided to us by Dynamic SDK. + +``` +export const DynamicWidgetButton: React.FC = () => { + return ( +
+ Wallet Interaction +
+ +
+
+ ); +}; + +``` + +- Now we can use and initialize the Dynamic wallet anywhere in our app by just using the above component! + +- Let's create our Main component in **page.tsx** file. + +In this file, we will [**useDynamicContext**](https://docs.dynamic.xyz/sdks/react-sdk/hooks/usedynamiccontext#header) provided by the dynamic sdk to fetch the wallet connected. We will also use this same wallet to execute all our ethers expression. + +``` + const { primaryWallet } = useDynamicContext(); +``` + +- In our application, we have built a basic **Signer** component which uses the connected Dynamic wallet to generate a signature from the user. + + +``` + const signMessage = async () => { + if (!primaryWallet) { + console.error("No primary wallet connected"); + return; + } + + try { + const signedMessage = await primaryWallet.connector.signMessage('You are signing an example message'); + if (signedMessage) { + setSignature(signedMessage); + } else { + setSignature(null); + } + } catch (error) { + console.error("Error signing message:", error); + setSignature(null); + } + }; +``` + +You can also see that the **signMessage** function is provided by the Dynamic SDK. So cool! + +## Using ethers + +The last piece of component, I want to discuss is the **getBalance** component. Although Dybamic also gives a component to fetch user balance, this function is created to demonstrate how you can use standard ethers expression to build out your app further. + +``` + const getBalance = async () => { + if (!primaryWallet) { + console.error("No primary wallet connected"); + return null; + } + + const provider = await primaryWallet.connector?.ethers?.getRpcProvider(); + + if (!provider) { + console.error("No provider available"); + return null; + } + try { + const balance = await provider.getBalance(primaryWallet.address); + console.log(balance); + return balance; + } catch (error) { + console.error("Error getting balance:", error); + return null; + } + }; + +``` + +## Demo Application + +You can check out this [**repository**](https://github.com/gnosischain/developer-resources/tree/main/custom-signers/dynamic-gnosis) for the full stack application demo. + diff --git a/docs/technicalguides/custom-signers/privy.md b/docs/technicalguides/custom-signers/privy.md new file mode 100644 index 00000000..0714ceb0 --- /dev/null +++ b/docs/technicalguides/custom-signers/privy.md @@ -0,0 +1,105 @@ +--- +description: Privy is a simple library to add beautiful authentication flows and powerful embedded wallets to your app. +keywords: [privy,custom-signers] +--- + +# Privy + +This guide will walk you through the steps to integrate the Privy Wallet and SDK into your Web3 DApp, with a specific configuration for the Gnosis chain(mainnet & Chiado testnet). + +![Privy Image](../../../static/img/signers/privy.png) + +## Guide + +The [Privy React SDK](https://www.npmjs.com/package/@privy-io/react-auth) is the easiest way to integrate Privy in your +application. + +In order to integrate the Privy React SDK, your project must be on: + +- a minimum React version of 18 +- a minimum TypeScript version of 5 + +### 1. Install the Privy React SDK + +```shell +npm install @privy-io/react-auth@latest +``` + +### 2. Setup Log-in methods & Privy App ID + +Navigate to your [Privy dashboard](https://dashboard.privy.io/apps) and from the **Login methods** methods tab, enable all the login methods you want the end-user to have. + +Also, note the **App ID** from the settings, we will need to configure while initializing Privy. + +### 3. Setup Privy Provider and Gnosis Config + +We can now initialize **PrivyProvider**. Replace the App ID field with your own Privy App ID and import the chains you want to support in your dapp. In our case, we have imported **gnosisChiado**. and **gnosis** from viem. We can also also cutomize with theme, logo and , colours and other [configs](https://docs.privy.io/guide/react/configuration/appearance#app-name). + +```shell +'use client'; + +import {PrivyProvider} from '@privy-io/react-auth'; +import {gnosisChiado, gnosis} from 'viem/chains'; + +export default function Providers({children}: {children: React.ReactNode}) { + return ( + + {children} + + ); +} +``` + + +You can now import the above component and wrap around your application in the **layout.tsx** file(In case of a NextJS app). + +Here is an example: + +```shell +import type { Metadata } from "next"; +import PrivyProvider from "./components/privy"; + +export const metadata: Metadata = { + title: "Gnosis App Demo", + description: "Gnosis App Demo", +}; + +export default function RootLayout({ + children, +}: Readonly<{ + children: React.ReactNode; +}>) { + return ( + + + + {children} + + + + ); +} + +``` + +## Demo Application + +Here is a full-stack dapp which showcases Privy integration along with proper configurations to fetch wallet data and make on-chain transactions. The application integrates the Pirvy React SDK and uses it to mint ERC-1155 tokens on the Gnosis Chiado testnet. + +[**Link to Demo Application**](https://github.com/gnosischain/developer-resources/tree/main/custom-signers/privy-gnosis) + diff --git a/static/img/bridges/hashi/Hashi-Gnosis-AMB.png b/static/img/bridges/hashi/Hashi-Gnosis-AMB.png new file mode 100644 index 00000000..c80ec505 Binary files /dev/null and b/static/img/bridges/hashi/Hashi-Gnosis-AMB.png differ diff --git a/static/img/bridges/hashi/Hashi-Gnosis-xDAI.png b/static/img/bridges/hashi/Hashi-Gnosis-xDAI.png new file mode 100644 index 00000000..46fa7182 Binary files /dev/null and b/static/img/bridges/hashi/Hashi-Gnosis-xDAI.png differ diff --git a/static/img/signers/dynamic.png b/static/img/signers/dynamic.png new file mode 100644 index 00000000..34ece332 Binary files /dev/null and b/static/img/signers/dynamic.png differ diff --git a/static/img/signers/privy.png b/static/img/signers/privy.png new file mode 100644 index 00000000..176a5601 Binary files /dev/null and b/static/img/signers/privy.png differ diff --git a/updates/2024/08-28-core-devs-call.md b/updates/2024/08-28-core-devs-call.md index 64747a21..d13849ca 100644 --- a/updates/2024/08-28-core-devs-call.md +++ b/updates/2024/08-28-core-devs-call.md @@ -1,5 +1,5 @@ --- -title: Core Devs Call - 2024/08/21 +title: Core Devs Call - 2024/08/28 authors: [dapplion, armaganercan, filoozom] tags: [CoreDevsCall, Gnosis Chain] --- @@ -86,3 +86,4 @@ Aug 28, 2024 * Started to integrate the Nethermind implementation * Might require a new repo +