diff --git a/develop/404.html b/develop/404.html index cd29c6a..f14eea6 100644 --- a/develop/404.html +++ b/develop/404.html @@ -4,13 +4,13 @@ Page Not Found | XDC Subnet - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/develop/assets/js/344489b7.7100cb5a.js b/develop/assets/js/344489b7.7100cb5a.js deleted file mode 100644 index 16ce876..0000000 --- a/develop/assets/js/344489b7.7100cb5a.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkxdc_subnet_docs=self.webpackChunkxdc_subnet_docs||[]).push([[586],{3905:(e,t,n)=>{n.d(t,{Zo:()=>d,kt:()=>k});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var p=r.createContext({}),s=function(e){var t=r.useContext(p),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},d=function(e){var t=s(e.components);return r.createElement(p.Provider,{value:t},e.children)},c="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},u=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,p=e.parentName,d=l(e,["components","mdxType","originalType","parentName"]),c=s(n),u=a,k=c["".concat(p,".").concat(u)]||c[u]||m[u]||o;return n?r.createElement(k,i(i({ref:t},d),{},{components:n})):r.createElement(k,i({ref:t},d))}));function k(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=u;var l={};for(var p in t)hasOwnProperty.call(t,p)&&(l[p]=t[p]);l.originalType=e,l[c]="string"==typeof e?e:a,i[1]=l;for(var s=2;s{n.r(t),n.d(t,{assets:()=>p,contentTitle:()=>i,default:()=>m,frontMatter:()=>o,metadata:()=>l,toc:()=>s});var r=n(7462),a=(n(7294),n(3905));const o={sidebar_label:"1. Launch a Subnet",sidebar_position:1},i="Launch a Subnet",l={unversionedId:"deployment/launch_subnet",id:"deployment/launch_subnet",title:"Launch a Subnet",description:"Overview",source:"@site/docs/deployment/1_launch_subnet.md",sourceDirName:"deployment",slug:"/deployment/launch_subnet",permalink:"/xdc-subnet-docs/deployment/launch_subnet",draft:!1,tags:[],version:"current",sidebarPosition:1,frontMatter:{sidebar_label:"1. Launch a Subnet",sidebar_position:1},sidebar:"defaultSidebar",previous:{title:"Deployment Guide",permalink:"/xdc-subnet-docs/category/deployment-guide"},next:{title:"2. Debug Guide (How to know if my subnet is running?)",permalink:"/xdc-subnet-docs/deployment/debug_guide"}},p={},s=[{value:"Overview",id:"overview",level:2},{value:"Requirements",id:"requirements",level:2},{value:"Steps",id:"steps",level:2},{value:"Removing Subnet",id:"removing-subnet",level:3}],d={toc:s},c="wrapper";function m(e){let{components:t,...n}=e;return(0,a.kt)(c,(0,r.Z)({},d,n,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h1",{id:"launch-a-subnet"},"Launch a Subnet"),(0,a.kt)("h2",{id:"overview"},"Overview"),(0,a.kt)("p",null," For the convenience of deploying Subnet, we have provided the Subnet Deployment Generator. The Subnet Deployment Generator is configuration generator for all components of subnet deployment. It generates all the necessary files and configs from a simple initial docker.env file. The required parameters are "),(0,a.kt)("pre",null,(0,a.kt)("code",{parentName:"pre"},"1. How many machines will you use to deploy subnet?\n2. How many subnet nodes will you deploy in total?\n3. IP address of the main machine\n4. Parentchain wallet with funds\n")),(0,a.kt)("p",null," In this setup the main machine (machine1) will host all the subnet services(relayer, stats, frontend) while the subnet miner nodes will be spread out among all machines."),(0,a.kt)("p",null," The IP address of the main machine is needed for subnet connectivity, this is the IP that is known to all other machines, could be private or public (preferrably private)"),(0,a.kt)("p",null," Once generated, the commands to startup the subnet is also provided as a generated ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," file."),(0,a.kt)("p",null," The deployment is docker based, the main deployment file is ",(0,a.kt)("inlineCode",{parentName:"p"},"docker-compose.yml"),". The ",(0,a.kt)("inlineCode",{parentName:"p"},"docker-compose.env")," is the injection point to all configs. Then, ENVs for the services and subnet nodes are in ",(0,a.kt)("inlineCode",{parentName:"p"},"*.env")," files. Other files include ",(0,a.kt)("inlineCode",{parentName:"p"},"genesis.json")," file to initialize subnet chain, ",(0,a.kt)("inlineCode",{parentName:"p"},"deployment.json")," to deploy the checkpoint smartcontract, and ",(0,a.kt)("inlineCode",{parentName:"p"},"keys.json")," the keypairs for subnet nodes + grandmaster node. Again, these files will be generated by the Subnet Deployment Generator (SDG)."),(0,a.kt)("h2",{id:"requirements"},"Requirements"),(0,a.kt)("ul",null,(0,a.kt)("li",{parentName:"ul"},(0,a.kt)("p",{parentName:"li"},"OS: Linux. Only Linux is supported for full deployment. ")),(0,a.kt)("li",{parentName:"ul"},(0,a.kt)("p",{parentName:"li"},"OS: Mac is only supported for single machine testing environment. Specify MacOS with 'OS=mac' in 'docker.env' file. Please also refer ",(0,a.kt)("a",{parentName:"p",href:"/xdc-subnet-docs/deployment/debug_guide#common-issues"},"common issues"),".")),(0,a.kt)("li",{parentName:"ul"},(0,a.kt)("p",{parentName:"li"},"docker, docker compose V2. For manual installation of docker compose V2 please refer to: ",(0,a.kt)("a",{parentName:"p",href:"https://docs.docker.com/compose/install/linux/"},"https://docs.docker.com/compose/install/linux/")))),(0,a.kt)("h2",{id:"steps"},"Steps"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Create a ",(0,a.kt)("inlineCode",{parentName:"p"},"docker.env")," file with parameters similar to ",(0,a.kt)("a",{parentName:"p",href:"https://github.com/XinFinOrg/XinFin-Node/blob/master/subnet/deployment-generator/script/docker.env.example"},(0,a.kt)("inlineCode",{parentName:"a"},"docker.env.example")),". Detailed parameters explanation ",(0,a.kt)("a",{parentName:"p",href:"/xdc-subnet-docs/deployment/configs_explanation"},"here"),".")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Pull the ",(0,a.kt)("inlineCode",{parentName:"p"},"generator.sh")," script from the generator Github repo"),(0,a.kt)("pre",{parentName:"li"},(0,a.kt)("code",{parentName:"pre"},"curl -O https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/subnet/deployment-generator/script/generate.sh\n"))),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Generate configurations, this will create a new ",(0,a.kt)("inlineCode",{parentName:"p"},"generated")," directory"),(0,a.kt)("pre",{parentName:"li"},(0,a.kt)("code",{parentName:"pre"},"chmod +x generate.sh\n./generate.sh\ncd generated\n"))),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"follow the generated instructions in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to start Subnet Nodes and ",(0,a.kt)("a",{parentName:"p",href:"/xdc-subnet-docs/deployment/debug_guide#subnet-nodes"},"make sure they are mining"),".")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"follow the generated instructions in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to deploy the upgradable Checkpoint Smart Contract(CSC). If CSC deployment was successful, you should see CSC addresses in ",(0,a.kt)("inlineCode",{parentName:"p"},"common.env"),", the added ENVs include ",(0,a.kt)("inlineCode",{parentName:"p"},"PROXY_GATEWAY"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"FULL_CSC"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"LITE_CSC"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"CHECKPOINT_CONTRACT"),".")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"follow the generated instructions in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to start the Subnet Services (relayer, stats-server, frontend)")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Check out the Subnet UI at ",(0,a.kt)("inlineCode",{parentName:"p"},":5555")))),(0,a.kt)("h3",{id:"removing-subnet"},"Removing Subnet"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Change the commands in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to ",(0,a.kt)("inlineCode",{parentName:"p"},"docker compose ... down")),(0,a.kt)("pre",{parentName:"li"},(0,a.kt)("code",{parentName:"pre"},"docker compose --env-file docker-compose.env --profile down \n"))),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Repeat 1. for every docker ",(0,a.kt)("inlineCode",{parentName:"p"},"--profile")," that was started. ")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Inside ",(0,a.kt)("inlineCode",{parentName:"p"},"generated")," directory, remove ",(0,a.kt)("inlineCode",{parentName:"p"},"bootnodes"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"stats-service"),", and ",(0,a.kt)("inlineCode",{parentName:"p"},"xdcchain*")," directories"))))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/develop/assets/js/344489b7.c2c72023.js b/develop/assets/js/344489b7.c2c72023.js new file mode 100644 index 0000000..b1e1e85 --- /dev/null +++ b/develop/assets/js/344489b7.c2c72023.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkxdc_subnet_docs=self.webpackChunkxdc_subnet_docs||[]).push([[586],{3905:(e,t,n)=>{n.d(t,{Zo:()=>d,kt:()=>k});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var p=r.createContext({}),s=function(e){var t=r.useContext(p),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},d=function(e){var t=s(e.components);return r.createElement(p.Provider,{value:t},e.children)},c="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},u=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,p=e.parentName,d=l(e,["components","mdxType","originalType","parentName"]),c=s(n),u=a,k=c["".concat(p,".").concat(u)]||c[u]||m[u]||o;return n?r.createElement(k,i(i({ref:t},d),{},{components:n})):r.createElement(k,i({ref:t},d))}));function k(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=u;var l={};for(var p in t)hasOwnProperty.call(t,p)&&(l[p]=t[p]);l.originalType=e,l[c]="string"==typeof e?e:a,i[1]=l;for(var s=2;s{n.r(t),n.d(t,{assets:()=>p,contentTitle:()=>i,default:()=>m,frontMatter:()=>o,metadata:()=>l,toc:()=>s});var r=n(7462),a=(n(7294),n(3905));const o={sidebar_label:"1. Launch a Subnet",sidebar_position:1},i=void 0,l={unversionedId:"deployment/launch_subnet",id:"deployment/launch_subnet",title:"launch_subnet",description:"Overview",source:"@site/docs/deployment/1_launch_subnet.md",sourceDirName:"deployment",slug:"/deployment/launch_subnet",permalink:"/xdc-subnet-docs/deployment/launch_subnet",draft:!1,tags:[],version:"current",sidebarPosition:1,frontMatter:{sidebar_label:"1. Launch a Subnet",sidebar_position:1},sidebar:"defaultSidebar",previous:{title:"Deployment Guide",permalink:"/xdc-subnet-docs/category/deployment-guide"},next:{title:"2. Debug Guide (How to know if my subnet is running?)",permalink:"/xdc-subnet-docs/deployment/debug_guide"}},p={},s=[{value:"Overview",id:"overview",level:2},{value:"Requirements",id:"requirements",level:2},{value:"Steps",id:"steps",level:2},{value:"Removing Subnet",id:"removing-subnet",level:3}],d={toc:s},c="wrapper";function m(e){let{components:t,...n}=e;return(0,a.kt)(c,(0,r.Z)({},d,n,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h1",{id:"launch-a-subnet"},"Launch a Subnet"),(0,a.kt)("h1",{id:"generate-subnet-configs-with-ui"},"Generate Subnet Configs With UI"),(0,a.kt)("h2",{id:"overview"},"Overview"),(0,a.kt)("p",null," For the convenience of deploying Subnet, we have provided the Subnet Deployment Generator. The Subnet Deployment Generator is configuration generator for all components of subnet deployment. It generates all the necessary files and configs from a simple initial docker.env file. The required parameters are "),(0,a.kt)("pre",null,(0,a.kt)("code",{parentName:"pre"},"1. How many machines will you use to deploy subnet?\n2. How many subnet nodes will you deploy in total?\n3. IP address of the main machine\n4. Parentchain wallet with funds\n")),(0,a.kt)("p",null," In this setup the main machine (machine1) will host all the subnet services(relayer, stats, frontend) while the subnet miner nodes will be spread out among all machines."),(0,a.kt)("p",null," The IP address of the main machine is needed for subnet connectivity, this is the IP that is known to all other machines, could be private or public (preferrably private)"),(0,a.kt)("p",null," Once generated, the commands to startup the subnet is also provided as a generated ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," file."),(0,a.kt)("p",null," The deployment is docker based, the main deployment file is ",(0,a.kt)("inlineCode",{parentName:"p"},"docker-compose.yml"),". The ",(0,a.kt)("inlineCode",{parentName:"p"},"docker-compose.env")," is the injection point to all configs. Then, ENVs for the services and subnet nodes are in ",(0,a.kt)("inlineCode",{parentName:"p"},"*.env")," files. Other files include ",(0,a.kt)("inlineCode",{parentName:"p"},"genesis.json")," file to initialize subnet chain, ",(0,a.kt)("inlineCode",{parentName:"p"},"deployment.json")," to deploy the checkpoint smartcontract, and ",(0,a.kt)("inlineCode",{parentName:"p"},"keys.json")," the keypairs for subnet nodes + grandmaster node. Again, these files will be generated by the Subnet Deployment Generator (SDG)."),(0,a.kt)("h2",{id:"requirements"},"Requirements"),(0,a.kt)("ul",null,(0,a.kt)("li",{parentName:"ul"},(0,a.kt)("p",{parentName:"li"},"OS: Linux. Only Linux is supported for full deployment. ")),(0,a.kt)("li",{parentName:"ul"},(0,a.kt)("p",{parentName:"li"},"OS: Mac is only supported for single machine testing environment. Specify MacOS with 'OS=mac' in 'docker.env' file. Please also refer ",(0,a.kt)("a",{parentName:"p",href:"/xdc-subnet-docs/deployment/debug_guide#common-issues"},"common issues"),".")),(0,a.kt)("li",{parentName:"ul"},(0,a.kt)("p",{parentName:"li"},"docker, docker compose V2. For manual installation of docker compose V2 please refer to: ",(0,a.kt)("a",{parentName:"p",href:"https://docs.docker.com/compose/install/linux/"},"https://docs.docker.com/compose/install/linux/")))),(0,a.kt)("h2",{id:"steps"},"Steps"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Create a ",(0,a.kt)("inlineCode",{parentName:"p"},"docker.env")," file with parameters similar to ",(0,a.kt)("a",{parentName:"p",href:"https://github.com/XinFinOrg/XinFin-Node/blob/master/subnet/deployment-generator/script/docker.env.example"},(0,a.kt)("inlineCode",{parentName:"a"},"docker.env.example")),". Detailed parameters explanation ",(0,a.kt)("a",{parentName:"p",href:"/xdc-subnet-docs/deployment/configs_explanation"},"here"),".")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Pull the ",(0,a.kt)("inlineCode",{parentName:"p"},"generator.sh")," script from the generator Github repo"),(0,a.kt)("pre",{parentName:"li"},(0,a.kt)("code",{parentName:"pre"},"curl -O https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/subnet/deployment-generator/script/generate.sh\n"))),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Generate configurations, this will create a new ",(0,a.kt)("inlineCode",{parentName:"p"},"generated")," directory"),(0,a.kt)("pre",{parentName:"li"},(0,a.kt)("code",{parentName:"pre"},"chmod +x generate.sh\n./generate.sh\ncd generated\n"))),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"follow the generated instructions in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to start Subnet Nodes and ",(0,a.kt)("a",{parentName:"p",href:"/xdc-subnet-docs/deployment/debug_guide#subnet-nodes"},"make sure they are mining"),".")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"follow the generated instructions in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to deploy the upgradable Checkpoint Smart Contract(CSC). If CSC deployment was successful, you should see CSC addresses in ",(0,a.kt)("inlineCode",{parentName:"p"},"common.env"),", the added ENVs include ",(0,a.kt)("inlineCode",{parentName:"p"},"PROXY_GATEWAY"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"FULL_CSC"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"LITE_CSC"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"CHECKPOINT_CONTRACT"),".")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"follow the generated instructions in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to start the Subnet Services (relayer, stats-server, frontend)")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Check out the Subnet UI at ",(0,a.kt)("inlineCode",{parentName:"p"},":5555")))),(0,a.kt)("h3",{id:"removing-subnet"},"Removing Subnet"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Change the commands in ",(0,a.kt)("inlineCode",{parentName:"p"},"commands.txt")," to ",(0,a.kt)("inlineCode",{parentName:"p"},"docker compose ... down")),(0,a.kt)("pre",{parentName:"li"},(0,a.kt)("code",{parentName:"pre"},"docker compose --env-file docker-compose.env --profile down \n"))),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Repeat 1. for every docker ",(0,a.kt)("inlineCode",{parentName:"p"},"--profile")," that was started. ")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Inside ",(0,a.kt)("inlineCode",{parentName:"p"},"generated")," directory, remove ",(0,a.kt)("inlineCode",{parentName:"p"},"bootnodes"),", ",(0,a.kt)("inlineCode",{parentName:"p"},"stats-service"),", and ",(0,a.kt)("inlineCode",{parentName:"p"},"xdcchain*")," directories"))))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/develop/assets/js/935f2afb.b0129636.js b/develop/assets/js/935f2afb.50e1692d.js similarity index 76% rename from develop/assets/js/935f2afb.b0129636.js rename to develop/assets/js/935f2afb.50e1692d.js index 8b2d1be..c91d807 100644 --- a/develop/assets/js/935f2afb.b0129636.js +++ b/develop/assets/js/935f2afb.50e1692d.js @@ -1 +1 @@ -"use strict";(self.webpackChunkxdc_subnet_docs=self.webpackChunkxdc_subnet_docs||[]).push([[53],{1109:e=>{e.exports=JSON.parse('{"pluginId":"default","version":"current","label":"Next","banner":null,"badge":false,"noIndex":false,"className":"docs-version-current","isLast":true,"docsSidebars":{"defaultSidebar":[{"type":"link","label":"Welcome","href":"/xdc-subnet-docs/","docId":"intro"},{"type":"category","label":"Introduction","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Motivation & Design Rationale","href":"/xdc-subnet-docs/introduction/intro","docId":"introduction/intro"},{"type":"link","label":"Architecture","href":"/xdc-subnet-docs/introduction/architecture","docId":"introduction/architecture"}],"href":"/xdc-subnet-docs/category/introduction"},{"type":"category","label":"Components","collapsible":true,"collapsed":true,"items":[{"type":"category","label":"Subnet Chain","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Design","href":"/xdc-subnet-docs/components/subnet/design","docId":"components/subnet/design"},{"type":"link","label":"API","href":"/xdc-subnet-docs/components/subnet/api","docId":"components/subnet/api"}],"href":"/xdc-subnet-docs/category/subnet-chain"},{"type":"category","label":"Checkpoint Smart Contract","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Design","href":"/xdc-subnet-docs/components/checkpoint_smart_contract/design","docId":"components/checkpoint_smart_contract/design"},{"type":"link","label":"Specs","href":"/xdc-subnet-docs/components/checkpoint_smart_contract/spec","docId":"components/checkpoint_smart_contract/spec"}],"href":"/xdc-subnet-docs/category/checkpoint-smart-contract"},{"type":"category","label":"Relayer","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Design","href":"/xdc-subnet-docs/components/relayer/design","docId":"components/relayer/design"},{"type":"link","label":"Relayer Mode","href":"/xdc-subnet-docs/components/relayer/relayer_mode","docId":"components/relayer/relayer_mode"}],"href":"/xdc-subnet-docs/category/relayer"},{"type":"category","label":"API Library","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Specs","href":"/xdc-subnet-docs/components/API_library/api","docId":"components/API_library/api"}],"href":"/xdc-subnet-docs/category/api-library"}],"href":"/xdc-subnet-docs/category/components"},{"type":"category","label":"Deployment Guide","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"1. Launch a Subnet","href":"/xdc-subnet-docs/deployment/launch_subnet","docId":"deployment/launch_subnet"},{"type":"link","label":"2. Debug Guide (How to know if my subnet is running?)","href":"/xdc-subnet-docs/deployment/debug_guide","docId":"deployment/debug_guide"},{"type":"link","label":"3. Deployment and Configs Explanation","href":"/xdc-subnet-docs/deployment/configs_explanation","docId":"deployment/configs_explanation"},{"type":"link","label":"4. Blockchain Explorer","href":"/xdc-subnet-docs/deployment/blockchain_explorer","docId":"deployment/blockchain_explorer"},{"type":"link","label":"5. Upgrading the Subnet","href":"/xdc-subnet-docs/deployment/upgrading_the_subnet","docId":"deployment/upgrading_the_subnet"},{"type":"link","label":"Subnet Deployment Generator Changelog","href":"/xdc-subnet-docs/deployment/subnet_deployment_generator_changelog","docId":"deployment/subnet_deployment_generator_changelog"}],"href":"/xdc-subnet-docs/category/deployment-guide"},{"type":"category","label":"UI Usage Guide","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Homepage","href":"/xdc-subnet-docs/usage/homepage","docId":"usage/homepage"},{"type":"link","label":"Confirmation Checker","href":"/xdc-subnet-docs/usage/confirmation_checker","docId":"usage/confirmation_checker"},{"type":"link","label":"Subnet Management","href":"/xdc-subnet-docs/usage/management","docId":"usage/management"}],"href":"/xdc-subnet-docs/category/ui-usage-guide"}]},"docs":{"components/API_library/api":{"id":"components/API_library/api","title":"Specifications","description":"TBW","sidebar":"defaultSidebar"},"components/checkpoint_smart_contract/design":{"id":"components/checkpoint_smart_contract/design","title":"Design","description":"Overview","sidebar":"defaultSidebar"},"components/checkpoint_smart_contract/spec":{"id":"components/checkpoint_smart_contract/spec","title":"spec","description":"APIs","sidebar":"defaultSidebar"},"components/relayer/design":{"id":"components/relayer/design","title":"Design","description":"Background","sidebar":"defaultSidebar"},"components/relayer/relayer_mode":{"id":"components/relayer/relayer_mode","title":"Relayer Mode","description":"There are 2 relayer modes \'Full\' and \'Lite\' where the default mode is \'Full\'. In the full mode, all subnet block headers are checkpointed to the parent chain. In the lite mode, only the Epoch and Epoch gap subnet block headers are checkpointed in the parent chain (blocks 451,900,1351,1800, and so on). The Epoch and Epoch gap blocks stores important information regarding subnet validators selection. For further reading please check Checkpoint Smart Contract.","sidebar":"defaultSidebar"},"components/subnet/api":{"id":"components/subnet/api","title":"API","description":"Subnet-specific APIs","sidebar":"defaultSidebar"},"components/subnet/design":{"id":"components/subnet/design","title":"Design","description":"XDC subnet is a blockchain network tailored for private and consortium use cases. It is powered by XDC2.0, which is the core engine of XDC network and enables state-of-the-art security against Byzantine attacks with forensics, fast transaction confirmation, and low energy consumption. It is also designed to enable secure checkpointing to XDC mainnet, so that it can harness the security, finality, and accountability of mainnet.","sidebar":"defaultSidebar"},"deployment/blockchain_explorer":{"id":"deployment/blockchain_explorer","title":"Blockchain Explorer","description":"You may optionally use an external blocks explorer if you require verbose browsing such as block detail, accounts browsing, contracts browsing. We can recommend Chainlens-free as one of the solution. Please follow the instructions as the previous link. You only need to pass one of the Subnet\'s RPC as a variable in the docker-compose command, which will most likely be NODEENDPOINT=http8545 or NODEENDPOINT=http8545.","sidebar":"defaultSidebar"},"deployment/configs_explanation":{"id":"deployment/configs_explanation","title":"Configs Explanation","description":"The kickstart file \'docker.env\'","sidebar":"defaultSidebar"},"deployment/debug_guide":{"id":"deployment/debug_guide","title":"Debug guide (how to know if my subnet is running?)","description":"## Subnet Nodes","sidebar":"defaultSidebar"},"deployment/launch_subnet":{"id":"deployment/launch_subnet","title":"Launch a Subnet","description":"Overview","sidebar":"defaultSidebar"},"deployment/subnet_deployment_generator_changelog":{"id":"deployment/subnet_deployment_generator_changelog","title":"Subnet Deployment Generator Changelog","description":"v0.3.2 - 2024/08/15","sidebar":"defaultSidebar"},"deployment/upgrading_the_subnet":{"id":"deployment/upgrading_the_subnet","title":"Upgrading the Subnet","description":"Upgrading the Checkpoing Smart Contract (CSC)","sidebar":"defaultSidebar"},"intro":{"id":"intro","title":"Welcome","description":"Welcome to the technical documentation site of XDC enterprise private subnet! We are continuously adding materials to it.","sidebar":"defaultSidebar"},"introduction/architecture":{"id":"introduction/architecture","title":"Architecture","description":"The architecture consists of the following four main components owned by the customer:","sidebar":"defaultSidebar"},"introduction/intro":{"id":"introduction/intro","title":"Motivation & Design Rationale","description":"As a leading Layer-1 (L1) public blockchain, XDC network has attrated many enterprise and institutional customers. Besides the high performance and high security that XDC already offers, these customers also demand privacy, meaning that their transactions and ledger should not be disclosed to the public. This requirement prohibits them from directly submitting transactions to XDC. Instead, they should only checkpoint snapshots of their ledger to XDC in order to extract XDC\'s security.","sidebar":"defaultSidebar"},"usage/confirmation_checker":{"id":"usage/confirmation_checker","title":"Confirmation Checker","description":"After navigating with the left menu bar to the Confirmation Checker of the Subnet, this will be shown.","sidebar":"defaultSidebar"},"usage/homepage":{"id":"usage/homepage","title":"Homepage","description":"Once subnet is successfully deployed. The homepage will show the following.","sidebar":"defaultSidebar"},"usage/management":{"id":"usage/management","title":"Subnet Management","description":"WIP","sidebar":"defaultSidebar"}}}')}}]); \ No newline at end of file +"use strict";(self.webpackChunkxdc_subnet_docs=self.webpackChunkxdc_subnet_docs||[]).push([[53],{1109:e=>{e.exports=JSON.parse('{"pluginId":"default","version":"current","label":"Next","banner":null,"badge":false,"noIndex":false,"className":"docs-version-current","isLast":true,"docsSidebars":{"defaultSidebar":[{"type":"link","label":"Welcome","href":"/xdc-subnet-docs/","docId":"intro"},{"type":"category","label":"Introduction","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Motivation & Design Rationale","href":"/xdc-subnet-docs/introduction/intro","docId":"introduction/intro"},{"type":"link","label":"Architecture","href":"/xdc-subnet-docs/introduction/architecture","docId":"introduction/architecture"}],"href":"/xdc-subnet-docs/category/introduction"},{"type":"category","label":"Components","collapsible":true,"collapsed":true,"items":[{"type":"category","label":"Subnet Chain","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Design","href":"/xdc-subnet-docs/components/subnet/design","docId":"components/subnet/design"},{"type":"link","label":"API","href":"/xdc-subnet-docs/components/subnet/api","docId":"components/subnet/api"}],"href":"/xdc-subnet-docs/category/subnet-chain"},{"type":"category","label":"Checkpoint Smart Contract","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Design","href":"/xdc-subnet-docs/components/checkpoint_smart_contract/design","docId":"components/checkpoint_smart_contract/design"},{"type":"link","label":"Specs","href":"/xdc-subnet-docs/components/checkpoint_smart_contract/spec","docId":"components/checkpoint_smart_contract/spec"}],"href":"/xdc-subnet-docs/category/checkpoint-smart-contract"},{"type":"category","label":"Relayer","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Design","href":"/xdc-subnet-docs/components/relayer/design","docId":"components/relayer/design"},{"type":"link","label":"Relayer Mode","href":"/xdc-subnet-docs/components/relayer/relayer_mode","docId":"components/relayer/relayer_mode"}],"href":"/xdc-subnet-docs/category/relayer"},{"type":"category","label":"API Library","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Specs","href":"/xdc-subnet-docs/components/API_library/api","docId":"components/API_library/api"}],"href":"/xdc-subnet-docs/category/api-library"}],"href":"/xdc-subnet-docs/category/components"},{"type":"category","label":"Deployment Guide","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"1. Launch a Subnet","href":"/xdc-subnet-docs/deployment/launch_subnet","docId":"deployment/launch_subnet"},{"type":"link","label":"2. Debug Guide (How to know if my subnet is running?)","href":"/xdc-subnet-docs/deployment/debug_guide","docId":"deployment/debug_guide"},{"type":"link","label":"3. Deployment and Configs Explanation","href":"/xdc-subnet-docs/deployment/configs_explanation","docId":"deployment/configs_explanation"},{"type":"link","label":"4. Blockchain Explorer","href":"/xdc-subnet-docs/deployment/blockchain_explorer","docId":"deployment/blockchain_explorer"},{"type":"link","label":"5. Upgrading the Subnet","href":"/xdc-subnet-docs/deployment/upgrading_the_subnet","docId":"deployment/upgrading_the_subnet"},{"type":"link","label":"Subnet Deployment Generator Changelog","href":"/xdc-subnet-docs/deployment/subnet_deployment_generator_changelog","docId":"deployment/subnet_deployment_generator_changelog"}],"href":"/xdc-subnet-docs/category/deployment-guide"},{"type":"category","label":"UI Usage Guide","collapsible":true,"collapsed":true,"items":[{"type":"link","label":"Homepage","href":"/xdc-subnet-docs/usage/homepage","docId":"usage/homepage"},{"type":"link","label":"Confirmation Checker","href":"/xdc-subnet-docs/usage/confirmation_checker","docId":"usage/confirmation_checker"},{"type":"link","label":"Subnet Management","href":"/xdc-subnet-docs/usage/management","docId":"usage/management"}],"href":"/xdc-subnet-docs/category/ui-usage-guide"}]},"docs":{"components/API_library/api":{"id":"components/API_library/api","title":"Specifications","description":"TBW","sidebar":"defaultSidebar"},"components/checkpoint_smart_contract/design":{"id":"components/checkpoint_smart_contract/design","title":"Design","description":"Overview","sidebar":"defaultSidebar"},"components/checkpoint_smart_contract/spec":{"id":"components/checkpoint_smart_contract/spec","title":"spec","description":"APIs","sidebar":"defaultSidebar"},"components/relayer/design":{"id":"components/relayer/design","title":"Design","description":"Background","sidebar":"defaultSidebar"},"components/relayer/relayer_mode":{"id":"components/relayer/relayer_mode","title":"Relayer Mode","description":"There are 2 relayer modes \'Full\' and \'Lite\' where the default mode is \'Full\'. In the full mode, all subnet block headers are checkpointed to the parent chain. In the lite mode, only the Epoch and Epoch gap subnet block headers are checkpointed in the parent chain (blocks 451,900,1351,1800, and so on). The Epoch and Epoch gap blocks stores important information regarding subnet validators selection. For further reading please check Checkpoint Smart Contract.","sidebar":"defaultSidebar"},"components/subnet/api":{"id":"components/subnet/api","title":"API","description":"Subnet-specific APIs","sidebar":"defaultSidebar"},"components/subnet/design":{"id":"components/subnet/design","title":"Design","description":"XDC subnet is a blockchain network tailored for private and consortium use cases. It is powered by XDC2.0, which is the core engine of XDC network and enables state-of-the-art security against Byzantine attacks with forensics, fast transaction confirmation, and low energy consumption. It is also designed to enable secure checkpointing to XDC mainnet, so that it can harness the security, finality, and accountability of mainnet.","sidebar":"defaultSidebar"},"deployment/blockchain_explorer":{"id":"deployment/blockchain_explorer","title":"Blockchain Explorer","description":"You may optionally use an external blocks explorer if you require verbose browsing such as block detail, accounts browsing, contracts browsing. We can recommend Chainlens-free as one of the solution. Please follow the instructions as the previous link. You only need to pass one of the Subnet\'s RPC as a variable in the docker-compose command, which will most likely be NODEENDPOINT=http8545 or NODEENDPOINT=http8545.","sidebar":"defaultSidebar"},"deployment/configs_explanation":{"id":"deployment/configs_explanation","title":"Configs Explanation","description":"The kickstart file \'docker.env\'","sidebar":"defaultSidebar"},"deployment/debug_guide":{"id":"deployment/debug_guide","title":"Debug guide (how to know if my subnet is running?)","description":"## Subnet Nodes","sidebar":"defaultSidebar"},"deployment/launch_subnet":{"id":"deployment/launch_subnet","title":"launch_subnet","description":"Overview","sidebar":"defaultSidebar"},"deployment/subnet_deployment_generator_changelog":{"id":"deployment/subnet_deployment_generator_changelog","title":"Subnet Deployment Generator Changelog","description":"v0.3.2 - 2024/08/15","sidebar":"defaultSidebar"},"deployment/upgrading_the_subnet":{"id":"deployment/upgrading_the_subnet","title":"Upgrading the Subnet","description":"Upgrading the Checkpoing Smart Contract (CSC)","sidebar":"defaultSidebar"},"intro":{"id":"intro","title":"Welcome","description":"Welcome to the technical documentation site of XDC enterprise private subnet! We are continuously adding materials to it.","sidebar":"defaultSidebar"},"introduction/architecture":{"id":"introduction/architecture","title":"Architecture","description":"The architecture consists of the following four main components owned by the customer:","sidebar":"defaultSidebar"},"introduction/intro":{"id":"introduction/intro","title":"Motivation & Design Rationale","description":"As a leading Layer-1 (L1) public blockchain, XDC network has attrated many enterprise and institutional customers. Besides the high performance and high security that XDC already offers, these customers also demand privacy, meaning that their transactions and ledger should not be disclosed to the public. This requirement prohibits them from directly submitting transactions to XDC. Instead, they should only checkpoint snapshots of their ledger to XDC in order to extract XDC\'s security.","sidebar":"defaultSidebar"},"usage/confirmation_checker":{"id":"usage/confirmation_checker","title":"Confirmation Checker","description":"After navigating with the left menu bar to the Confirmation Checker of the Subnet, this will be shown.","sidebar":"defaultSidebar"},"usage/homepage":{"id":"usage/homepage","title":"Homepage","description":"Once subnet is successfully deployed. The homepage will show the following.","sidebar":"defaultSidebar"},"usage/management":{"id":"usage/management","title":"Subnet Management","description":"WIP","sidebar":"defaultSidebar"}}}')}}]); \ No newline at end of file diff --git a/develop/assets/js/runtime~main.0b2f3418.js b/develop/assets/js/runtime~main.0b2f3418.js new file mode 100644 index 0000000..9192181 --- /dev/null +++ b/develop/assets/js/runtime~main.0b2f3418.js @@ -0,0 +1 @@ +(()=>{"use strict";var e,a,t,r,o,c={},b={};function d(e){var a=b[e];if(void 0!==a)return a.exports;var t=b[e]={id:e,loaded:!1,exports:{}};return c[e].call(t.exports,t,t.exports,d),t.loaded=!0,t.exports}d.m=c,d.c=b,e=[],d.O=(a,t,r,o)=>{if(!t){var c=1/0;for(i=0;i=o)&&Object.keys(d.O).every((e=>d.O[e](t[f])))?t.splice(f--,1):(b=!1,o0&&e[i-1][2]>o;i--)e[i]=e[i-1];e[i]=[t,r,o]},d.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return d.d(a,{a:a}),a},t=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,d.t=function(e,r){if(1&r&&(e=this(e)),8&r)return e;if("object"==typeof e&&e){if(4&r&&e.__esModule)return e;if(16&r&&"function"==typeof e.then)return e}var o=Object.create(null);d.r(o);var c={};a=a||[null,t({}),t([]),t(t)];for(var b=2&r&&e;"object"==typeof b&&!~a.indexOf(b);b=t(b))Object.getOwnPropertyNames(b).forEach((a=>c[a]=()=>e[a]));return c.default=()=>e,d.d(o,c),o},d.d=(e,a)=>{for(var t in a)d.o(a,t)&&!d.o(e,t)&&Object.defineProperty(e,t,{enumerable:!0,get:a[t]})},d.f={},d.e=e=>Promise.all(Object.keys(d.f).reduce(((a,t)=>(d.f[t](e,a),a)),[])),d.u=e=>"assets/js/"+({53:"935f2afb",60:"a0d00db3",75:"20a671be",85:"1f391b9e",98:"97f28a37",110:"a34667f7",131:"686a4056",140:"f5e9ed0e",163:"70ba180a",164:"d1976c08",176:"9ca9f017",257:"961c9c8a",265:"63b83a25",268:"c2dcec65",337:"e7f2f223",355:"61bbba59",414:"393be207",416:"01a9496d",473:"b0a6d0fa",475:"00b375aa",488:"0273b01b",506:"a66cc553",514:"1be78505",586:"344489b7",611:"3b02e8c7",671:"0e384e19",743:"f8551aab",817:"14eb3368",865:"0385815d",868:"06d48bbd",876:"03181aef",918:"17896441",955:"341d1452",967:"8861aab2",977:"70e9807b",985:"c1845702",989:"51ab4d20"}[e]||e)+"."+{53:"50e1692d",60:"7a78306e",75:"df5ab5c6",85:"223778a2",98:"0e1f3a88",110:"3064a95f",131:"4847214b",140:"e19d2a23",163:"f7c446b9",164:"34d2852b",176:"ba1dc76f",257:"142967e3",265:"8c1b4342",268:"46112d88",337:"62664920",355:"fb815d38",414:"ecd64a6e",416:"27cce949",473:"aa93b597",475:"242a9942",488:"141059a2",506:"f56387f5",514:"08d54c61",586:"c2c72023",611:"5f4f25eb",666:"7c9539e4",671:"39ee22b2",743:"e9901e47",817:"de3fdfd7",865:"533ac150",868:"1583f65e",876:"dbb9741c",918:"0fc9f395",955:"ded3c8ef",967:"a6e7dc13",972:"9334dfaa",977:"8ffe3ccb",985:"6fdc7451",989:"a3ec8426"}[e]+".js",d.miniCssF=e=>{},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),r={},o="xdc-subnet-docs:",d.l=(e,a,t,c)=>{if(r[e])r[e].push(a);else{var b,f;if(void 0!==t)for(var n=document.getElementsByTagName("script"),i=0;i{b.onerror=b.onload=null,clearTimeout(s);var o=r[e];if(delete r[e],b.parentNode&&b.parentNode.removeChild(b),o&&o.forEach((e=>e(t))),a)return a(t)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:b}),12e4);b.onerror=l.bind(null,b.onerror),b.onload=l.bind(null,b.onload),f&&document.head.appendChild(b)}},d.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},d.p="/xdc-subnet-docs/",d.gca=function(e){return e={17896441:"918","935f2afb":"53",a0d00db3:"60","20a671be":"75","1f391b9e":"85","97f28a37":"98",a34667f7:"110","686a4056":"131",f5e9ed0e:"140","70ba180a":"163",d1976c08:"164","9ca9f017":"176","961c9c8a":"257","63b83a25":"265",c2dcec65:"268",e7f2f223:"337","61bbba59":"355","393be207":"414","01a9496d":"416",b0a6d0fa:"473","00b375aa":"475","0273b01b":"488",a66cc553:"506","1be78505":"514","344489b7":"586","3b02e8c7":"611","0e384e19":"671",f8551aab:"743","14eb3368":"817","0385815d":"865","06d48bbd":"868","03181aef":"876","341d1452":"955","8861aab2":"967","70e9807b":"977",c1845702:"985","51ab4d20":"989"}[e]||e,d.p+d.u(e)},(()=>{var e={303:0,532:0};d.f.j=(a,t)=>{var r=d.o(e,a)?e[a]:void 0;if(0!==r)if(r)t.push(r[2]);else if(/^(303|532)$/.test(a))e[a]=0;else{var o=new Promise(((t,o)=>r=e[a]=[t,o]));t.push(r[2]=o);var c=d.p+d.u(a),b=new Error;d.l(c,(t=>{if(d.o(e,a)&&(0!==(r=e[a])&&(e[a]=void 0),r)){var o=t&&("load"===t.type?"missing":t.type),c=t&&t.target&&t.target.src;b.message="Loading chunk "+a+" failed.\n("+o+": "+c+")",b.name="ChunkLoadError",b.type=o,b.request=c,r[1](b)}}),"chunk-"+a,a)}},d.O.j=a=>0===e[a];var a=(a,t)=>{var r,o,c=t[0],b=t[1],f=t[2],n=0;if(c.some((a=>0!==e[a]))){for(r in b)d.o(b,r)&&(d.m[r]=b[r]);if(f)var i=f(d)}for(a&&a(t);n{"use strict";var e,a,t,r,o,c={},d={};function f(e){var a=d[e];if(void 0!==a)return a.exports;var t=d[e]={id:e,loaded:!1,exports:{}};return c[e].call(t.exports,t,t.exports,f),t.loaded=!0,t.exports}f.m=c,f.c=d,e=[],f.O=(a,t,r,o)=>{if(!t){var c=1/0;for(i=0;i=o)&&Object.keys(f.O).every((e=>f.O[e](t[b])))?t.splice(b--,1):(d=!1,o0&&e[i-1][2]>o;i--)e[i]=e[i-1];e[i]=[t,r,o]},f.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return f.d(a,{a:a}),a},t=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,f.t=function(e,r){if(1&r&&(e=this(e)),8&r)return e;if("object"==typeof e&&e){if(4&r&&e.__esModule)return e;if(16&r&&"function"==typeof e.then)return e}var o=Object.create(null);f.r(o);var c={};a=a||[null,t({}),t([]),t(t)];for(var d=2&r&&e;"object"==typeof d&&!~a.indexOf(d);d=t(d))Object.getOwnPropertyNames(d).forEach((a=>c[a]=()=>e[a]));return c.default=()=>e,f.d(o,c),o},f.d=(e,a)=>{for(var t in a)f.o(a,t)&&!f.o(e,t)&&Object.defineProperty(e,t,{enumerable:!0,get:a[t]})},f.f={},f.e=e=>Promise.all(Object.keys(f.f).reduce(((a,t)=>(f.f[t](e,a),a)),[])),f.u=e=>"assets/js/"+({53:"935f2afb",60:"a0d00db3",75:"20a671be",85:"1f391b9e",98:"97f28a37",110:"a34667f7",131:"686a4056",140:"f5e9ed0e",163:"70ba180a",164:"d1976c08",176:"9ca9f017",257:"961c9c8a",265:"63b83a25",268:"c2dcec65",337:"e7f2f223",355:"61bbba59",414:"393be207",416:"01a9496d",473:"b0a6d0fa",475:"00b375aa",488:"0273b01b",506:"a66cc553",514:"1be78505",586:"344489b7",611:"3b02e8c7",671:"0e384e19",743:"f8551aab",817:"14eb3368",865:"0385815d",868:"06d48bbd",876:"03181aef",918:"17896441",955:"341d1452",967:"8861aab2",977:"70e9807b",985:"c1845702",989:"51ab4d20"}[e]||e)+"."+{53:"b0129636",60:"7a78306e",75:"df5ab5c6",85:"223778a2",98:"0e1f3a88",110:"3064a95f",131:"4847214b",140:"e19d2a23",163:"f7c446b9",164:"34d2852b",176:"ba1dc76f",257:"142967e3",265:"8c1b4342",268:"46112d88",337:"62664920",355:"fb815d38",414:"ecd64a6e",416:"27cce949",473:"aa93b597",475:"242a9942",488:"141059a2",506:"f56387f5",514:"08d54c61",586:"7100cb5a",611:"5f4f25eb",666:"7c9539e4",671:"39ee22b2",743:"e9901e47",817:"de3fdfd7",865:"533ac150",868:"1583f65e",876:"dbb9741c",918:"0fc9f395",955:"ded3c8ef",967:"a6e7dc13",972:"9334dfaa",977:"8ffe3ccb",985:"6fdc7451",989:"a3ec8426"}[e]+".js",f.miniCssF=e=>{},f.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),f.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),r={},o="xdc-subnet-docs:",f.l=(e,a,t,c)=>{if(r[e])r[e].push(a);else{var d,b;if(void 0!==t)for(var n=document.getElementsByTagName("script"),i=0;i{d.onerror=d.onload=null,clearTimeout(s);var o=r[e];if(delete r[e],d.parentNode&&d.parentNode.removeChild(d),o&&o.forEach((e=>e(t))),a)return a(t)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:d}),12e4);d.onerror=l.bind(null,d.onerror),d.onload=l.bind(null,d.onload),b&&document.head.appendChild(d)}},f.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.p="/xdc-subnet-docs/",f.gca=function(e){return e={17896441:"918","935f2afb":"53",a0d00db3:"60","20a671be":"75","1f391b9e":"85","97f28a37":"98",a34667f7:"110","686a4056":"131",f5e9ed0e:"140","70ba180a":"163",d1976c08:"164","9ca9f017":"176","961c9c8a":"257","63b83a25":"265",c2dcec65:"268",e7f2f223:"337","61bbba59":"355","393be207":"414","01a9496d":"416",b0a6d0fa:"473","00b375aa":"475","0273b01b":"488",a66cc553:"506","1be78505":"514","344489b7":"586","3b02e8c7":"611","0e384e19":"671",f8551aab:"743","14eb3368":"817","0385815d":"865","06d48bbd":"868","03181aef":"876","341d1452":"955","8861aab2":"967","70e9807b":"977",c1845702:"985","51ab4d20":"989"}[e]||e,f.p+f.u(e)},(()=>{var e={303:0,532:0};f.f.j=(a,t)=>{var r=f.o(e,a)?e[a]:void 0;if(0!==r)if(r)t.push(r[2]);else if(/^(303|532)$/.test(a))e[a]=0;else{var o=new Promise(((t,o)=>r=e[a]=[t,o]));t.push(r[2]=o);var c=f.p+f.u(a),d=new Error;f.l(c,(t=>{if(f.o(e,a)&&(0!==(r=e[a])&&(e[a]=void 0),r)){var o=t&&("load"===t.type?"missing":t.type),c=t&&t.target&&t.target.src;d.message="Loading chunk "+a+" failed.\n("+o+": "+c+")",d.name="ChunkLoadError",d.type=o,d.request=c,r[1](d)}}),"chunk-"+a,a)}},f.O.j=a=>0===e[a];var a=(a,t)=>{var r,o,c=t[0],d=t[1],b=t[2],n=0;if(c.some((a=>0!==e[a]))){for(r in d)f.o(d,r)&&(f.m[r]=d[r]);if(b)var i=b(f)}for(a&&a(t);n API Library | XDC Subnet - +

API Library

This section specifies the API library we develop for the subnet users to confirm subnet transactions.

- + \ No newline at end of file diff --git a/develop/category/checkpoint-smart-contract/index.html b/develop/category/checkpoint-smart-contract/index.html index 8b5c5db..5b91b07 100644 --- a/develop/category/checkpoint-smart-contract/index.html +++ b/develop/category/checkpoint-smart-contract/index.html @@ -4,13 +4,13 @@ Checkpoint Smart Contract | XDC Subnet - +

Checkpoint Smart Contract

This section specifies the Checkpoint Smart Contract in the parent chain that protects the child chain.

- + \ No newline at end of file diff --git a/develop/category/components/index.html b/develop/category/components/index.html index 79ac8bf..e09c8e1 100644 --- a/develop/category/components/index.html +++ b/develop/category/components/index.html @@ -4,13 +4,13 @@ Components | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/category/deployment-guide/index.html b/develop/category/deployment-guide/index.html index 53c1ed8..bdef74c 100644 --- a/develop/category/deployment-guide/index.html +++ b/develop/category/deployment-guide/index.html @@ -4,13 +4,13 @@ Deployment Guide | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/category/introduction/index.html b/develop/category/introduction/index.html index 1fad131..10eaa45 100644 --- a/develop/category/introduction/index.html +++ b/develop/category/introduction/index.html @@ -4,13 +4,13 @@ Introduction | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/category/relayer/index.html b/develop/category/relayer/index.html index 276d7e4..8c78914 100644 --- a/develop/category/relayer/index.html +++ b/develop/category/relayer/index.html @@ -4,13 +4,13 @@ Relayer | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/category/subnet-chain/index.html b/develop/category/subnet-chain/index.html index 3d8ee6c..a255272 100644 --- a/develop/category/subnet-chain/index.html +++ b/develop/category/subnet-chain/index.html @@ -4,13 +4,13 @@ Subnet Chain | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/category/ui-usage-guide/index.html b/develop/category/ui-usage-guide/index.html index 54443df..b7e36ed 100644 --- a/develop/category/ui-usage-guide/index.html +++ b/develop/category/ui-usage-guide/index.html @@ -4,13 +4,13 @@ UI Usage Guide | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/components/API_library/api/index.html b/develop/components/API_library/api/index.html index e354f87..4a17484 100644 --- a/develop/components/API_library/api/index.html +++ b/develop/components/API_library/api/index.html @@ -4,13 +4,13 @@ Specifications | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/components/checkpoint_smart_contract/design/index.html b/develop/components/checkpoint_smart_contract/design/index.html index 395e834..c5aa0de 100644 --- a/develop/components/checkpoint_smart_contract/design/index.html +++ b/develop/components/checkpoint_smart_contract/design/index.html @@ -4,13 +4,13 @@ Design | XDC Subnet - +

Design

Overview​

The primary function of the parent chain smart contract is to receive block data from the subnet node, verify it, and store it.

Noteworthy aspects:

  • Every block data received will be verified to ensure the signature is signed by validators and has passed with 2/3 of the votes.

  • In the gap block occurring in the middle of each epoch, a next may appear, which will be selected for temporary storage.

  • In each epoch block, a current may appear, which will choose the next selected during the gap as validators from the current block to the next epoch.

  • Only three consecutive blocks of roundNumber can confirm the previous block, and mainnetNum will change from -1 to block.number once the block is committed.

Overview

Specifics​

Checkpoint​

The Checkpoint contract implements a blockchain checkpoint system, which verifies and stores block header information for subnetworks. Here are some key functions and features:

  • The contract defines several data structures, such as Header, HeaderInfo, Validators and BlockLite. These structures are used to store block header information, validator information, and more.

  • The contract employs several mappings and other variables to track the current block header tree, committed blocks, validator set, latest block, and so forth.

  • The contract's constructor receives the initial validator set, the genesis block header, the first block header, etc., as parameters and initializes the contract state based on these.

  • The receiveHeader function allows users to submit new block headers. This function will verify the meta information of the block header (like block number, parent block hash, etc.), the signature certificate, and update the block's submission status when specific conditions are met.

  • Functions such as setLookup, setCommittedStatus, checkUniqueness, and checkCommittedStatus are used to update or check the contract's internal status.

  • Functions like getHeader, getHeaderByNumber, getLatestBlocks and getCurrentValidators enable users to query block header information, validator sets, etc.

  • The splitSignature and recoverSigner functions are used to recover the signer's address from the signature, which is necessary for verifying the block header signature.

Logic Flow:

  1. Checkpoint uses the following parameters for contract construction:

    • address[] initial_validator_set : List of initial validator addresses
    • bytes genesis_header: block0HexRLP
    • bytes block1_header: block1HexRLP
    • uint64 gap: GAP block number on public chain
    • uint64 epoch: EPOCH block number on public chain

  2. Relayers need to fetch every block data from the subnet node.

  3. Users can retrieve the information of each block using methods such as getHeader.

Checkpoint

Lite Checkpoint​

Lite Checkpoint is a lightweight block header checkpoint. It implements several functions, including:

  • Setting the initial validator set and related parameters during contract initialization.
  • Checking whether the submitted block header meets the requirements.
  • Receiving and processing submitted block headers.
  • Submitting the block header and block header by block number.
  • Retrieving uncommitted block header information.
  • Accessing specific block header information.
  • Fetching the current and next round of epoch blocks according to the index.
  • Getting the latest block information.
  • Accessing the current set of validators.

Logic Flow:

  1. Lite Checkpoint uses the following parameters for contract construction:

    • address[] initialValidatorSet : List of initial validator addresses
    • bytes block1: block1HexRLP
    • uint64 gap: GAP block number on public chain
    • uint64 epoch: EPOCH block number on public chain

  2. Relayers only need to fetch gap/epoch block data and fetch the following consecutive roundNumber blocks to confirm the signed gap/epoch block from the subnet node.

  3. Users can get gap/epoch block information from methods such as getHeader.

Lite Checkpoint

Upgradeable module​

The Upgradeable module mainly revolves around the concept of transparent proxies and the ability to upgrade the underlying logic contracts without changing the contract's address.

ProxyGateway Smart Contract​

The ProxyGateway smart contract plays a central role in this module. It inherits from ProxyAdmin and primarily serves the purpose of creating and managing transparent upgradeable proxies (TransparentUpgradeableProxy).

Key Components and Functionalities:

  • cscProxies:

    • A mapping used to store two types of transparent upgradeable proxies.
      • 0 represents "full"
      • 1 represents "lite"

  • CreateProxy Event:

    • Emitted whenever a new transparent upgradeable proxy is created.

  • createProxy Function:

    • Creates a new TransparentUpgradeableProxy.
    • Emits the CreateProxy event upon creation.

  • createFullProxy Function:

    • Specifically designed for creating a transparent upgradeable proxy of type "full".
    • Checks if a "full" type proxy already exists.
    • Ensures the provided logic contract has a MODE function that returns "full".

  • createLiteProxy Function:

    • Designed for creating proxies of type "lite".
    • Checks if a "lite" type proxy already exists.
    • Ensures the provided logic contract has a MODE function that returns "lite".

Alt text

Logic Flow:

  1. Initialization:

    The process begins with the ProxyGateway contract, which serves as a central hub for creating transparent upgradeable proxies. The contract owner has the capability to create either "full" or "lite" proxies.

  2. Proxy Creation:

    • The owner calls either the createFullProxy or createLiteProxy function based on the desired type of proxy.
    • The specified logic contract's MODE is checked to ensure it matches the desired proxy type.
    • A new TransparentUpgradeableProxy is created with the specified logic contract, the ProxyGateway as the admin, and any necessary initialization data.
    • The new proxy's address is stored in the cscProxies mapping under its corresponding type.
    • The CreateProxy event is emitted to log the creation of the new proxy.

  3. Upgrading the Proxy:

    When there's a need to upgrade the underlying logic of the proxy (for instance, to introduce new features or fix bugs):

    • A new logic contract version is deployed to the network.
    • The owner (or authorized entity) of the ProxyGateway contract calls the inherited upgrade function from ProxyAdmin to point the proxy to the new logic contract.
    • The proxy now delegates all calls to the new logic contract, while still retaining all its previous storage and state.
    • This enables the system to evolve and implement new functionalities without migrating to a new contract address or affecting the contract's stored data.

  4. Interacting with the Proxy:

    Users and other contracts can interact with the proxy just as they would with a regular contract. However, behind the scenes, all function calls and data accesses are delegated to the current logic contract that the proxy points to.

  5. Querying and Data Access:

    Users and contracts can still query data, access functions, or invoke transactions on the proxy's address. The proxy transparently delegates these to the underlying logic contract, ensuring continuity of operations.

  6. Advanced Management:

    Through the ProxyAdmin functionality, the owner can further manage the proxy, such as changing the admin or even downgrading to a previous version of the logic contract if needed.

Alt text

- + \ No newline at end of file diff --git a/develop/components/checkpoint_smart_contract/spec/index.html b/develop/components/checkpoint_smart_contract/spec/index.html index 4193517..d7dc884 100644 --- a/develop/components/checkpoint_smart_contract/spec/index.html +++ b/develop/components/checkpoint_smart_contract/spec/index.html @@ -4,13 +4,13 @@ spec | XDC Subnet - +

spec

APIs​

  • Functions that have access restriction to authorized client

    • reviseValidatorSet(address[], int, int): Update subnet block header signer list at destined height
    • receiveHeader(bytes[]): Validate and store subnet headers

  • Functions that open for public access

    • getHeader(byte32): Return entire block header in RLP encoding format
    • getHeaderByNumber(int): Return block hash and number at input height
    • getHeaderConfirmationStatus(byte32): Return block committing status
    • getMainnetBlockNumber(byte32): Return mainnet block number that processed the subnet block header
    • getLatestBlocks(): Return latest committed block and submitted block

Algorithms and Rules​

Block header verification follows two principle rules:

  1. Received block should have consistent round number and block number associated with its parent block.
  2. Received block should have enough certificates signed by the list of block signers.

Once a block header is checked and stored, the contract will examine whether there are 3 consecutive blocks that have 3 consetive round number. If that is the case, all of the direct ancestor blocks that are prior to these 3 consecutive blocks will be committed.

- + \ No newline at end of file diff --git a/develop/components/relayer/design/index.html b/develop/components/relayer/design/index.html index 7e551fa..0ca0e7d 100644 --- a/develop/components/relayer/design/index.html +++ b/develop/components/relayer/design/index.html @@ -4,13 +4,13 @@ Design | XDC Subnet - +

Design

Background​

There is a strong demand from the banking industry to adopt XDC. One of the key requirements to enter the field is the ability to support subnets so that banks are able to keep the sensitive transactions within their own domain (privacy concern) but at the same time, have the ability to continuously audit the result (hash) of the subnet transactions on the XDC mainnet (security concern).

Since the mainnet and subnets will be running as two independent node cluster, we will need to figure out a method to bridge them together to perform the auditing feature mentioned above. This is where “relayer” is coming into play.

High-level architectural diagram​

At high level, the relayer is able to:

  1. Pull necessary data from both subnet and mainnet
  2. Process and submit subnet block data as smart contract transactions into mainnet
  3. When subnet masternodes list changes, report the new list and change height to the mainnet using grand-master account.

architectural-diagram

- + \ No newline at end of file diff --git a/develop/components/relayer/relayer_mode/index.html b/develop/components/relayer/relayer_mode/index.html index 421ee40..2fe96c9 100644 --- a/develop/components/relayer/relayer_mode/index.html +++ b/develop/components/relayer/relayer_mode/index.html @@ -4,13 +4,13 @@ Relayer Mode | XDC Subnet - +

Relayer Mode

There are 2 relayer modes 'Full' and 'Lite' where the default mode is 'Full'. In the full mode, all subnet block headers are checkpointed to the parent chain. In the lite mode, only the Epoch and Epoch gap subnet block headers are checkpointed in the parent chain (blocks 451,900,1351,1800, and so on). The Epoch and Epoch gap blocks stores important information regarding subnet validators selection. For further reading please check Checkpoint Smart Contract.

Choosing Full or Lite Relayer​

The Full mode has the advantage of being more 'complete' and more 'current' as blocks are getting confirmed in the parent chain almost immediately. The Lite mode has the advantage of using lower parent chain gas fee as the Relayer is only submitting to once every 450 blocks.

Deployment​

In the deployment RELAYER_MODE config is only relevant for Checkpoint Smart Contract (CSC) deployment. The relayer itself is able to detect the CSC type automatically and push block headers accordingly.

- + \ No newline at end of file diff --git a/develop/components/subnet/api/index.html b/develop/components/subnet/api/index.html index 0737368..525025b 100644 --- a/develop/components/subnet/api/index.html +++ b/develop/components/subnet/api/index.html @@ -4,13 +4,13 @@ API | XDC Subnet - +
- + \ No newline at end of file diff --git a/develop/components/subnet/design/index.html b/develop/components/subnet/design/index.html index c6ba77a..e5dbd65 100644 --- a/develop/components/subnet/design/index.html +++ b/develop/components/subnet/design/index.html @@ -4,13 +4,13 @@ Design | XDC Subnet - +

Design

XDC subnet is a blockchain network tailored for private and consortium use cases. It is powered by XDC2.0, which is the core engine of XDC network and enables state-of-the-art security against Byzantine attacks with forensics, fast transaction confirmation, and low energy consumption. It is also designed to enable secure checkpointing to XDC mainnet, so that it can harness the security, finality, and accountability of mainnet.

XDC2.0 Protocol​

As the core engine of both XDC mainnet and subnet, XDC2.0 maintains the consistency of the blockchain with strong security and performance guarantees. The Delegated Proof-of-Stake subprotocol elects a committee of masternodes. The masternodes run the state-of-the-art HotStuff consensus subprotocol to settle block generation and verification and confirm transactions. Besides, XDC2.0 protocol enables its unique feature, namely forensic monitoring. When the adversary corrupts more than 1/3 masternodes and violates safety, forensic monitoring can detect those actions and report irrefutable evidence of the culprits.

The distinction between XDC2.0 for subnet and mainnet is that for subnet the masternodes are permissioned whereas for mainnet they are permissionless.

Your Own Blockchain Network​

XDC subnet is completely owned by you. You, the owner of the subnet, are capable of controlling several aspects of the subnet.

First, the owner regulates the master node list. More specifically, the join/retire of mater nodes is done by smart contract calls that only the owner has access to. Also, underperforming or misbehaving masternodes could be expelled by the owner. This is in contrast with XDC mainnet, where masternodes join or leave willingly as long as they follow the rule enforced by the protocol.

Second, the blockchain genesis can be configured by the owner. The owner is able to distribute initial tokens and create accounts, as well as deploy system-level smart contracts on the blockchain.

Last, the owner can customize blockchain parameters, such as epoch length, max masternode number, the quorum certificate threshold, the reward per epoch, etc.

Integrating with XDC mainnet​

Integrating with XDC mainnet will enable subnet to harness the security, finality, and accountability of XDC mainnet. This requires the subnet owner to deploy a smart contract (XDC will provide) to XDC mainnet and report block headers and masternode changes to the smart contract.

As long as the mainnet is secure, the block header information of the subnet is securely stored on the mainnet. Users can also query the mainnet for finality to enhance the confidence that the subnet transaction is indeed finalized. The subnet can also report the culprits to the forensic server of XDC mainnet when its forensic monitor module detects safety violations. When the culprit report is validated, necessary measurements should be taken by the owner to reestablish the security of the subnet.

It is worth noting that the subnet can be deployed as a standalone, independent blockchain network without integrating with XDC mainnet. The choice is up to the owner whether to harness the advantages of XDC mainnet.

- + \ No newline at end of file diff --git a/develop/deployment/blockchain_explorer/index.html b/develop/deployment/blockchain_explorer/index.html index 54d2ea5..8d2ce66 100644 --- a/develop/deployment/blockchain_explorer/index.html +++ b/develop/deployment/blockchain_explorer/index.html @@ -4,13 +4,13 @@ Blockchain Explorer | XDC Subnet - +

Blockchain Explorer

You may optionally use an external blocks explorer if you require verbose browsing such as block detail, accounts browsing, contracts browsing. We can recommend Chainlens-free as one of the solution. Please follow the instructions as the previous link. You only need to pass one of the Subnet's RPC as a variable in the docker-compose command, which will most likely be NODE_ENDPOINT=http://localhost:8545 or NODE_ENDPOINT=http://<MAIN_IP>:8545.

- + \ No newline at end of file diff --git a/develop/deployment/configs_explanation/index.html b/develop/deployment/configs_explanation/index.html index 55d85f0..5b6c268 100644 --- a/develop/deployment/configs_explanation/index.html +++ b/develop/deployment/configs_explanation/index.html @@ -4,13 +4,13 @@ Configs Explanation | XDC Subnet - +

Configs Explanation

The kickstart file 'docker.env'​

docker.env is the basefile which kickstarts all configs generation

Required Parameters​

Below is an example of the mimimum file required for configs generation.

#deployment config
CONFIG_PATH=~/subnet/

#subnet config
NETWORK_NAME=testsubnet
NUM_SUBNET=5
NUM_MACHINE=3
MAIN_IP=192.168.1.1

#parentchain config
PARENTNET=devnet
PARENTNET_WALLET_PK=0x0000000000000000000000000000000000000000000000000000000000000000

  1. CONFIG_PATH - This is the path to the directory where you want to put the generated configs. Most likely it is your current directory. This ENV will be auto generated to the current directory if not included.

  2. NETWORK_NAME - Your subnet Name

  3. NUM_SUBNET - The total number of subnet nodes you want to deploy.

  4. NUM_MACHINE - The number of machines that you want to deploy the subnet across. The generated configs will evenly spread the nodes across the machines.

  5. MAIN_IP - The IP address of the main machine(machine1) which will host subnet services and the bootnode. This IP should be known to all other machines, could be private or public (preferrably private).

  6. PARENTNET - The Parentchain where the Checkpoint Smart Contract (CSC) will be deployed and where relayer will push block headers. Available: 'devnet', 'testnet', 'mainnet'. (Currently only 'devnet' is supported)

  7. PARENTNET_WALLET_PK - The private key of Parentchain wallet

    Optional Parameters​

    Versions Config​

    By default, generated configs will use the current stable version which is hard coded in the generator (not latest). To customize version the specific component version parameter can be included. Set the value to the docker image version tag you want (eg. VERSION_SUBNET=v0.1.3, VERSION_RELAYER=latest). Brose XDC dockerhub to check the available docker images. Below are the available parameters for versioning.

    VERSION_SUBNET
    VERSION_BOOTNODE
    VERSION_RELAYER
    VERSION_STATS
    VERSION_FRONTEND

    Other Configs​

  • RELAYER_MODE - 'full' or 'lite', this effects the type of Checkpoint Smart Contract(CSC) that the Relayer runs. Defaults to 'full'. Please check here for relayer mode documentation.
  • GRANDMASTER_PK - The Grandmaster privatekey, only one is allowed. Random if not provided.
  • SUBNETS_PK - Subnet nodes' privatekeys, multiple keys separated by comma(,). Number of keys must equal NUM_SUBNET. Randomized by default.
  • OS - 'linux' or 'mac', default 'linux'. 'mac' is an optional value for single machine testing environment on MacOS. The docker compose setup is differrent due to docker network limitation.
  • NETWORK_ID - If you want a specific number, must be between 1-65536. Default is random.
  • SERVICES_SECRET - A shared secret for authentication between the stats service and the subnet nodes. Default to a random string.

Files under 'generated' directory​

After the generator has succesfully run, all generated files will be under 'generated' directory. These files can be edited if you would like to further customize your subnet. Below is a description of each generated file and how it is used.

  • commands.txt - The generated instructions to launch the subnet.
  • docker-compose.yml - The main deployment file. Includes docker images versions, startup commands, network configurations.
  • docker-compose.env - The config injection path that docker uses to point to other *.env files.
  • genesis.json - The 'block 0' of the Subnet. Initializes the blockchain for subnet nodes.
  • genesis_input.yml - An intermediate file used in config generation.
  • deployment.config.json - The config file used for CSC deployment.
  • keys.json - Generated keypairs or custom keypairs by user input. Please be mindful to remove this file and keep the credentials securely.
  • common.env - The config parameters for Subnet services.
  • subnet*.env - The config parameters for each Subnet node.

Subnet Ports​

  1. Subnet Nodes - 3 ports are used per each subnet, RPC port, WS port, and Peering port. The port number is incremented by 1 for the next subnet node. For example subnet1's RPC is 8545, subnet2's RPC will be 8546 and so on.
  • RPC PORT - 8545, 8546, 8547, ... This is the API port, for outside chain communication to issue transaction or query chaindata.
  • WS PORT - 9555, 9556, 9557, ... This is not used currently.
  • Peering port - 20303, 20304, 20305, ... This is used for subnet nodes and bootnode peering and communication.
  • Subnet ports config can be changed in subnetX.env for each individual subnet.
  1. Bootnode - port 20301
  • Bootnode port can be changed at BOOTNODE_PORT under common.env. Also in each subnetX.env, BOOTNODES port has to be changed.
  1. Stats Server (UI backend) - port 3000.
  • To change this change left value inside docker-compose.yml stats port config. For example 3001:3000 will deploy on port 3001. In each subnetX.env file, STATS_SERVICE_ADDRESS port needs to be changed. In common.env, VITE_SUBNET_URL port also needs to change.
  1. Relayer - port 4000.
  • The Relayer port is used for Relayer tasks UI which tracks scheduled, completed, failed tasks.
  1. UI Frontend - port 5555.
  • To change this change left value inside docker-compose.yml frontend port config. For example 6666:5555 will deploy on port 6666. Then restart the docker image.
- + \ No newline at end of file diff --git a/develop/deployment/debug_guide/index.html b/develop/deployment/debug_guide/index.html index 68f5fdf..b89576e 100644 --- a/develop/deployment/debug_guide/index.html +++ b/develop/deployment/debug_guide/index.html @@ -4,13 +4,13 @@ Debug guide (how to know if my subnet is running?) | XDC Subnet - +

Debug guide (how to know if my subnet is running?)

Subnet Nodes​

  1. Check chainstate with curl, you can change localhost:8545 to your subnet node's RPC PORT

    Call latest block api, there should not be error and blocks should increase with time.

    curl --location 'http://localhost:8545' \
    --header 'Content-Type: application/json' \
    --data '{"jsonrpc":"2.0","method":"XDPoS_getV2BlockByNumber","params":["latest"],"id":1}'

    Check current peers, there should be NUM_SUBNET-1 peers

    curl --location 'http://localhost:8545' \
    --header 'Content-Type: application/json' \
    --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}'

  2. Check chainstate inside docker

    Exec into the subnet container

    docker exec -it <container_name> bash

    Attach to the API process

    XDC attach /work/xdcchain/XDC.ipc

    Call current block api

    XDPoS.getV2Block()

    Check current peers

    admin.peers

  3. Check logs, assuming log level 4 (default 2), you want to look for logs with blockNum, and blockNum should increase with time.

    docker logs -f <container_name>

Subnet Services​

  1. Bootnode

    Check logs, you should see messages from all subnet nodes

    docker logs -f <container_name>

  2. Relayer

    Check logs, you should see blocks being periodically submitted

    docker logs -f <container_name>

  3. Stats-server

    Check logs, in <deployment folder>/stats-service/logs/debug, you should see block data and history data being received.

  4. Frontend

    Check logs or check errors through developer console in web browser.

Common Issues​

  1. Subnet node does not boot with error log Fatal: Error starting protocol stack: listen unix /work/xdcchain/XDC.ipc: bind: invalid argument

    This is due to the volume mount path being too long. The mounth path is your current directory (also can check with pwd command). Please move the generated folder to a shorter path and try again.

  2. Docker image startup fails with SIGKILL or Error code: 137 found in logs. (Issue found in Frontend image)

    This error occurs because Docker ran Out Of Memory (OOM). You can increase the memory limit in Docker settings

- + \ No newline at end of file diff --git a/develop/deployment/launch_subnet/index.html b/develop/deployment/launch_subnet/index.html index 94b2b4a..783e29c 100644 --- a/develop/deployment/launch_subnet/index.html +++ b/develop/deployment/launch_subnet/index.html @@ -3,14 +3,14 @@ -Launch a Subnet | XDC Subnet - +launch_subnet | XDC Subnet +
-

Launch a Subnet

Overview​

For the convenience of deploying Subnet, we have provided the Subnet Deployment Generator. The Subnet Deployment Generator is configuration generator for all components of subnet deployment. It generates all the necessary files and configs from a simple initial docker.env file. The required parameters are 

1. How many machines will you use to deploy subnet?
2. How many subnet nodes will you deploy in total?
3. IP address of the main machine
4. Parentchain wallet with funds

In this setup the main machine (machine1) will host all the subnet services(relayer, stats, frontend) while the subnet miner nodes will be spread out among all machines.

The IP address of the main machine is needed for subnet connectivity, this is the IP that is known to all other machines, could be private or public (preferrably private)

Once generated, the commands to startup the subnet is also provided as a generated commands.txt file.

The deployment is docker based, the main deployment file is docker-compose.yml. The docker-compose.env is the injection point to all configs. Then, ENVs for the services and subnet nodes are in *.env files. Other files include genesis.json file to initialize subnet chain, deployment.json to deploy the checkpoint smartcontract, and keys.json the keypairs for subnet nodes + grandmaster node. Again, these files will be generated by the Subnet Deployment Generator (SDG).

Requirements​

  • OS: Linux. Only Linux is supported for full deployment.

  • OS: Mac is only supported for single machine testing environment. Specify MacOS with 'OS=mac' in 'docker.env' file. Please also refer common issues.

  • docker, docker compose V2. For manual installation of docker compose V2 please refer to: https://docs.docker.com/compose/install/linux/

Steps​

  1. Create a docker.env file with parameters similar to docker.env.example. Detailed parameters explanation here.

  2. Pull the generator.sh script from the generator Github repo

    curl -O https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/subnet/deployment-generator/script/generate.sh

  3. Generate configurations, this will create a new generated directory

    chmod +x generate.sh
    ./generate.sh
    cd generated

  4. follow the generated instructions in commands.txt to start Subnet Nodes and make sure they are mining.

  5. follow the generated instructions in commands.txt to deploy the upgradable Checkpoint Smart Contract(CSC). If CSC deployment was successful, you should see CSC addresses in common.env, the added ENVs include PROXY_GATEWAY, FULL_CSC, LITE_CSC, CHECKPOINT_CONTRACT.

  6. follow the generated instructions in commands.txt to start the Subnet Services (relayer, stats-server, frontend)

  7. Check out the Subnet UI at <MAIN_IP>:5555

Removing Subnet​

  1. Change the commands in commands.txt to docker compose ... down

    docker compose --env-file docker-compose.env --profile <profile_name> down

  2. Repeat 1. for every docker --profile that was started.

  3. Inside generated directory, remove bootnodes, stats-service, and xdcchain* directories

- +

launch_subnet

Launch a Subnet

Generate Subnet Configs With UI

Overview​

For the convenience of deploying Subnet, we have provided the Subnet Deployment Generator. The Subnet Deployment Generator is configuration generator for all components of subnet deployment. It generates all the necessary files and configs from a simple initial docker.env file. The required parameters are 

1. How many machines will you use to deploy subnet?
2. How many subnet nodes will you deploy in total?
3. IP address of the main machine
4. Parentchain wallet with funds

In this setup the main machine (machine1) will host all the subnet services(relayer, stats, frontend) while the subnet miner nodes will be spread out among all machines.

The IP address of the main machine is needed for subnet connectivity, this is the IP that is known to all other machines, could be private or public (preferrably private)

Once generated, the commands to startup the subnet is also provided as a generated commands.txt file.

The deployment is docker based, the main deployment file is docker-compose.yml. The docker-compose.env is the injection point to all configs. Then, ENVs for the services and subnet nodes are in *.env files. Other files include genesis.json file to initialize subnet chain, deployment.json to deploy the checkpoint smartcontract, and keys.json the keypairs for subnet nodes + grandmaster node. Again, these files will be generated by the Subnet Deployment Generator (SDG).

Requirements​

  • OS: Linux. Only Linux is supported for full deployment.

  • OS: Mac is only supported for single machine testing environment. Specify MacOS with 'OS=mac' in 'docker.env' file. Please also refer common issues.

  • docker, docker compose V2. For manual installation of docker compose V2 please refer to: https://docs.docker.com/compose/install/linux/

Steps​

  1. Create a docker.env file with parameters similar to docker.env.example. Detailed parameters explanation here.

  2. Pull the generator.sh script from the generator Github repo

    curl -O https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/subnet/deployment-generator/script/generate.sh

  3. Generate configurations, this will create a new generated directory

    chmod +x generate.sh
    ./generate.sh
    cd generated

  4. follow the generated instructions in commands.txt to start Subnet Nodes and make sure they are mining.

  5. follow the generated instructions in commands.txt to deploy the upgradable Checkpoint Smart Contract(CSC). If CSC deployment was successful, you should see CSC addresses in common.env, the added ENVs include PROXY_GATEWAY, FULL_CSC, LITE_CSC, CHECKPOINT_CONTRACT.

  6. follow the generated instructions in commands.txt to start the Subnet Services (relayer, stats-server, frontend)

  7. Check out the Subnet UI at <MAIN_IP>:5555

Removing Subnet​

  1. Change the commands in commands.txt to docker compose ... down

    docker compose --env-file docker-compose.env --profile <profile_name> down

  2. Repeat 1. for every docker --profile that was started.

  3. Inside generated directory, remove bootnodes, stats-service, and xdcchain* directories

+ \ No newline at end of file diff --git a/develop/deployment/subnet_deployment_generator_changelog/index.html b/develop/deployment/subnet_deployment_generator_changelog/index.html index dff3a89..b192818 100644 --- a/develop/deployment/subnet_deployment_generator_changelog/index.html +++ b/develop/deployment/subnet_deployment_generator_changelog/index.html @@ -4,14 +4,14 @@ Subnet Deployment Generator Changelog | XDC Subnet - +

Subnet Deployment Generator Changelog

v0.3.2 - 2024/08/15​

  • Changed frontend default due to clashing from 5000 to 5555

v0.3.1 - 2024/07/24​

  • Use testnet by default
  • Remove admin api by default
  • Added PUBLIC_IP optional config in deployment-generator
  • Bump component versions

v0.2.1 - 2024/01/09​

  • New generation style, pulls script from github to run multiple docker images instead of generating from single image.
  • New Checkpoint Smart Contract (CSC) deployment image
  • Supports upgradable CSC
  • Bump components versions
  • Fix bugs
  • Code refactor, optimization

v0.1.6​

  • Bump relayer version to support gas fee changes

v0.1.5​

  • Added OS=mac option in 'docker.env'. This option is intended for single machine testing environment only.

v0.1.4​

  • Added custom keys functionality 'docker.env' now accepts GRANDMASTER_PK and SUBNETS_PK. Where SUBNETS_PK can have multiple keys separated by a comma ','. Number of subnet keys must equal NUM_SUBNET. Keys are randomized if not provided.
  • Added RELAYER_MODE in 'docker.env', CSC deployment will select from 'full' or 'lite' smart contract, default 'full'.
  • Automate CHECKPOINT_CONTRACT copy-paste step (manual action no longer required).
  • PARENTCHAIN_WALLET is no longer required in 'docker.env', the address will be derived from PARENTCHAIN_WALLET_PK.
  • Disabled parentchain observer in docker-compose.yml, unused for now (due to long startup time).
  • Bump default subnet components stable versions
- + \ No newline at end of file diff --git a/develop/deployment/upgrading_the_subnet/index.html b/develop/deployment/upgrading_the_subnet/index.html index ae0b01b..39d4346 100644 --- a/develop/deployment/upgrading_the_subnet/index.html +++ b/develop/deployment/upgrading_the_subnet/index.html @@ -4,13 +4,13 @@ Upgrading the Subnet | XDC Subnet - +

Upgrading the Subnet

Upgrading the Checkpoing Smart Contract (CSC)​

The CSC is deployed as an upgradable smart contract. For further reading please check XDC-CSC. Upgrading can only be done by the original wallet that deployed the CSC. Under generated directory, specify the private key in common.env with the ENV PARENTNET_WALLET_PK. Then run the following command, specify the CSC version to upgrade with <CSC_VERSION> as a docker tag. 

docker run --env-file common.env   \
  -v $(pwd)/../generated/:/app/config       \
  --network host                             \
  --entrypoint './docker/upgrade_csc.sh' xinfinorg/csc:<CSC_VERSION>

If the CSC upgrade keeps failing, it could be due to these 2 common reasons:

  1. The wallet is out of funds.
  2. The wallet is being used somewhere else causing a transaction clash, eg. the Relayer is using the same wallet.

Upgrading Subnet deployment​

  1. Go to docker-compose.yml under generated directory.
  2. Change the docker image tag of your desired component(s).
  3. Run:
  docker compose --env-file docker-compose.env --profile machine1 up -d
  docker compose --env-file docker-compose.env --profile services up -d

Using latest tag is not recommended since not all components version are not guaranteed to be compatible.

- + \ No newline at end of file diff --git a/develop/index.html b/develop/index.html index 8cd8b0f..1e8d0c0 100644 --- a/develop/index.html +++ b/develop/index.html @@ -4,13 +4,13 @@ Welcome | XDC Subnet - +

Welcome

Welcome to the technical documentation site of XDC enterprise private subnet! We are continuously adding materials to it.

- + \ No newline at end of file diff --git a/develop/introduction/architecture/index.html b/develop/introduction/architecture/index.html index f98d501..dbb623b 100644 --- a/develop/introduction/architecture/index.html +++ b/develop/introduction/architecture/index.html @@ -4,13 +4,13 @@ Architecture | XDC Subnet - +

Architecture

The architecture consists of the following four main components owned by the customer:

  1. a subnet driven by the XDC2.0 consensus engine, with configurable parameters
  2. a relayer program that checkpoints subnet block headers to the XDC mainnet
  3. a smart contract in the XDC mainnet that verifies and records the checkpoints and maintain the subnet header chain
  4. an API library for the wallet, which enables additional protection of subnet transactions through extra confirmation in the XDC mainnet

Docs Version Dropdown

- + \ No newline at end of file diff --git a/develop/introduction/intro/index.html b/develop/introduction/intro/index.html index 800d7c9..f705c74 100644 --- a/develop/introduction/intro/index.html +++ b/develop/introduction/intro/index.html @@ -4,13 +4,13 @@ Motivation & Design Rationale | XDC Subnet - +

Motivation & Design Rationale

As a leading Layer-1 (L1) public blockchain, XDC network has attrated many enterprise and institutional customers. Besides the high performance and high security that XDC already offers, these customers also demand privacy, meaning that their transactions and ledger should not be disclosed to the public. This requirement prohibits them from directly submitting transactions to XDC. Instead, they should only checkpoint snapshots of their ledger to XDC in order to extract XDC's security.

From a system perspective, "security via checkpointing" is achieved via Layer-2 (L2) techniques, such as rollups and subnets. The most popular rollup technique, namely optimistic rollup, is not suitable for our use case. This is because while transaction execution is offloaded to L2, all these L2 transactions are still submitted to L1 as a record. Another popular rollup called zero-knowledge (ZK) rollup solves this problem. But ZK computation is slow, and the type of use cases it can currently support is very limited (such as token transfers), which cannot fulfill the diverse business needs of XDC's enterprise and institutional customers.

On the other hand, subnet is a perfect solution. By subnet, the customer runs a blockchain and checkpoints its critical consensus data to the parent chain. This way, not only is privacy preserved, the subnet can have its own security and resiliency besides those provided by the parent chain. This is particularly useful to enterprise and institutional customers who may collaborate with untrusted partners. A common criticism against subnet solutions is the high entry bar and operational cost of running a blockchain. However, in XDC's case, this is indeed welcomed becomes enterprise and institutional customers prefer owning the infrastructure in a private and isolated domain.

Motivated by this opportunity, XDC's core protocol team has tailor-designed a subnet solution for XDC's enterprise and institutional customers. It has the following main features:

  1. the subnet will be a sovereign, permissioned, and high-performing blockchain wholly owned by the customer.
  2. the subnet will be driven by XDC2.0, the most advanced and secure consensus engine originally-built for XDC in-house, and will be deployed to the XDC mainnet, too.
  3. a security level equivalent to the sum security of the subnet AND XDC mainnet.
  4. native EVM smart contract support.
  5. total privacy (i.e., no visibility) of the subset transactions on the XDC mainnet.
  6. full access and compatibility to XDC's abundant SDK and tools, such as the explorer and forensic monitoring system.
- + \ No newline at end of file diff --git a/develop/markdown-page/index.html b/develop/markdown-page/index.html index 83aa1ca..3189a23 100644 --- a/develop/markdown-page/index.html +++ b/develop/markdown-page/index.html @@ -4,13 +4,13 @@ Markdown page example | XDC Subnet - +

Markdown page example

You don't need React to write simple standalone pages.

- + \ No newline at end of file diff --git a/develop/my-markdown-page/index.html b/develop/my-markdown-page/index.html index 11d4347..8c3f6aa 100644 --- a/develop/my-markdown-page/index.html +++ b/develop/my-markdown-page/index.html @@ -4,13 +4,13 @@ My Markdown page | XDC Subnet - +

My Markdown page

This is a Markdown page

- + \ No newline at end of file diff --git a/develop/my-react-page/index.html b/develop/my-react-page/index.html index 1ac7ba2..9405584 100644 --- a/develop/my-react-page/index.html +++ b/develop/my-react-page/index.html @@ -4,13 +4,13 @@ XDC Subnet - +

My React page

This is a React page

- + \ No newline at end of file diff --git a/develop/usage/confirmation_checker/index.html b/develop/usage/confirmation_checker/index.html index 0659db4..cf1a83e 100644 --- a/develop/usage/confirmation_checker/index.html +++ b/develop/usage/confirmation_checker/index.html @@ -4,13 +4,13 @@ Confirmation Checker | XDC Subnet - +

Confirmation Checker

After navigating with the left menu bar to the Confirmation Checker of the Subnet, this will be shown.

Confirmation Checker 1

The input box accepts Block height, Block hash, and even TX hash.

After your input, the search engine will traverse the chain and display the info accodingly. Below is an example of Block height search.

Confirmation Checker 2

  1. Confirmation status of the block (or the block that TX belongs to)
  2. The block detailed information
  3. The Parentchain block where the Subnet block was recorded

Next is another example of a Block hash search.

Confirmation Checker 3

  1. Confirmation status of the block (or the block that TX belongs to)
  2. The block detailed information
  3. As the Subnet block has not been checkpointed in the Parentchain, the UI is displaying height 0.
- + \ No newline at end of file diff --git a/develop/usage/homepage/index.html b/develop/usage/homepage/index.html index 1a8e3c0..69a0f86 100644 --- a/develop/usage/homepage/index.html +++ b/develop/usage/homepage/index.html @@ -4,13 +4,13 @@ Homepage | XDC Subnet - +

Homepage

Once subnet is successfully deployed. The homepage will show the following.

Homepage 1

  1. The Subnet blockchain state. You can see the current 'Not Confirmed' and 'Confirmed' blocks. 'Confirmed' or 'committed' blocks should be 3 blocks behind latest blocks.
  2. The Subnet blockchain AS KNOWN by the Parentchain. The Relayer periodically calls the Checkpoint Smart Contract to update the Subnet status (default every 2 minutes).
  3. The Network Info card shows the Subnet throughput state, by default Blocktime should be every 2 seconds. It also indicates the Parentchain network
  4. The Relayer Info card shows the Relayer status. Which Checkpoint Smart Contract (CSC) it calls, Subnet blocks in the backlog, and the remaining wallet funds.
  5. The Masternodes Info card shows the Subnet nodes status. By default, all Subnet nodes are Masternodes and all should be active.

In the lower half of the homepage there are more information as shown.

Homepage 2

  1. This card shows further details of subnet blocks, including their height, hash, proposer, and confirmation status. The left side of 'confirmation status' shows the block being committed in the Subnet chain and the right side shows the block hash being recorded in the Parent chain.

  2. This card shows a detailed view of the subnet nodes including their address. The status also differrentiates inactive nodes to 'penalty' or 'standby'

  3. Additionally, you can select the UI theme (light or dark) by toggling this button.

- + \ No newline at end of file diff --git a/develop/usage/management/index.html b/develop/usage/management/index.html index 6625c9b..168ea0f 100644 --- a/develop/usage/management/index.html +++ b/develop/usage/management/index.html @@ -4,13 +4,13 @@ Subnet Management | XDC Subnet - +
- + \ No newline at end of file