├── .gitignore ├── LANGS.md ├── LICENSE ├── README.md ├── docs ├── .vuepress │ ├── config.js │ ├── public │ │ ├── android-chrome-192x192.png │ │ ├── android-chrome-512x512.png │ │ ├── app-tut-designer.png │ │ ├── app-tut-developer.png │ │ ├── app-tut-execute.png │ │ ├── app-tut-menu-list.png │ │ ├── app-tut-menu-messages.png │ │ ├── app-tut-navigation.png │ │ ├── app-tut-table.png │ │ ├── apple-touch-icon.png.png │ │ ├── block-fork-resolution.png │ │ ├── block-generation.png │ │ ├── favicon-16x16.png │ │ ├── favicon-32x32.png │ │ ├── ibax-eco.png │ │ ├── ibax.ico │ │ ├── ibax.png │ │ ├── manifest.webmanifest │ │ └── safari-pinned-tab.svg │ └── styles │ │ ├── ebook.css │ │ ├── index.styl │ │ ├── palette.styl │ │ └── runoob.css ├── README.md ├── concepts │ ├── about-the-platform.md │ ├── blockchain-layers.md │ ├── consensus.md │ ├── faq.md │ └── thesaurus.md ├── de │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── es │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── fr │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── howtos │ └── deployment.md ├── it │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── ja │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── kr │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── reference │ ├── api2.md │ ├── backend-config.md │ ├── desync_monitor.md │ ├── json-rpc.md │ └── platform-parameters.md ├── topics │ ├── daemons.md │ ├── script.md │ ├── templates2.md │ └── vm.md ├── tr-TR │ ├── README.md │ ├── concepts │ │ ├── about-the-platform.md │ │ ├── blockchain-layers.md │ │ ├── consensus.md │ │ ├── faq.md │ │ └── thesaurus.md │ ├── howtos │ │ └── deployment.md │ ├── reference │ │ ├── api2.md │ │ ├── backend-config.md │ │ ├── desync_monitor.md │ │ ├── json-rpc.md │ │ └── platform-parameters.md │ ├── topics │ │ ├── daemons.md │ │ ├── script.md │ │ ├── templates2.md │ │ └── vm.md │ └── tutorials │ │ ├── app_tutorial.md │ │ └── tutorial.md ├── tutorials │ ├── app_tutorial.md │ └── tutorial.md └── zh-CN │ ├── README.md │ ├── concepts │ ├── about-the-platform.md │ ├── blockchain-layers.md │ ├── consensus.md │ ├── faq.md │ └── thesaurus.md │ ├── howtos │ └── deployment.md │ ├── reference │ ├── api2.md │ ├── backend-config.md │ ├── desync_monitor.md │ ├── json-rpc.md │ └── platform-parameters.md │ ├── topics │ ├── daemons.md │ ├── script.md │ ├── templates2.md │ └── vm.md │ └── tutorials │ ├── app_tutorial.md │ └── tutorial.md ├── markdown_fix_link_anchor.py ├── package.json ├── syncDist.sh └── yarn.lock /.gitignore: -------------------------------------------------------------------------------- 1 | _book 2 | Thumbs.db 3 | /node_modules 4 | /yarn-error.log 5 | /docs/.vuepress/dist 6 | /ibax-io.github.io 7 | /.idea 8 | /docs/.idea -------------------------------------------------------------------------------- /LANGS.md: -------------------------------------------------------------------------------- 1 | * [English](en-US) 2 | * [Deutsch](de) 3 | * [Español](es) 4 | * [Français](fr) 5 | * [Português](pt-br) 6 | * [Italiano](it) 7 | * [العربية](ar) 8 | * [azərbaycan dili](az) 9 | * [беларуская мова](be) 10 | * [català](ca) 11 | * [čeština, český jazyk](cs) 12 | * [Esperanto](eo) 13 | * [suomi](fi) 14 | * [हिन्दी, हिंदी](hi) 15 | * [Magyar](hu) 16 | * [Bahasa Indonesia](id) 17 | * [日本語 (にほんご)](ja) 18 | * [한국어, 조선어](ko) 19 | * [македонски јазик](mk) 20 | * [Nederlands](nl) 21 | * [język polski](pl) 22 | * [limba română](ro) 23 | * [русский язык](ru) 24 | * [српски језик](sr) 25 | * [ไทย](th) 26 | * [Türkçe](tr) 27 | * [Tiếng Việt](vi) 28 | * [漢語](zh-tw) 29 | * [中文](zh-CN) 30 | 31 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IBAX Documentation 2 | 3 | 4 | - [Deutsch](docs/de/README.md) - [English](docs/README.md) - [Español](docs/es/README.md) - [Français](docs/fr/README.md) - [Italiano](docs/it/README.md) - [Türkçe](docs/tr-TR/README.md) - [日本語](docs/ja/README.md) - [简体中文](docs/zh-CN/README.md) - [한국인](docs/kr/README.md) 5 | 6 | 7 | ## Project setup 8 | ```shell 9 | yarn install 10 | ``` 11 | 12 | ## Compiles 13 | 14 | ### Run 15 | ```shell 16 | yarn dev 17 | ``` 18 | 19 | 20 | ### Build 21 | ```shell 22 | yarn build 23 | ``` 24 | 25 | 26 | ## Deploy 27 | ```shell 28 | ./syncDist.sh 29 | ``` 30 | -------------------------------------------------------------------------------- /docs/.vuepress/public/android-chrome-192x192.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/android-chrome-192x192.png -------------------------------------------------------------------------------- /docs/.vuepress/public/android-chrome-512x512.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/android-chrome-512x512.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-designer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-designer.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-developer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-developer.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-execute.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-execute.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-menu-list.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-menu-list.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-menu-messages.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-menu-messages.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-navigation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-navigation.png -------------------------------------------------------------------------------- /docs/.vuepress/public/app-tut-table.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/app-tut-table.png -------------------------------------------------------------------------------- /docs/.vuepress/public/apple-touch-icon.png.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/apple-touch-icon.png.png -------------------------------------------------------------------------------- /docs/.vuepress/public/block-fork-resolution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/block-fork-resolution.png -------------------------------------------------------------------------------- /docs/.vuepress/public/block-generation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/block-generation.png -------------------------------------------------------------------------------- /docs/.vuepress/public/favicon-16x16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/favicon-16x16.png -------------------------------------------------------------------------------- /docs/.vuepress/public/favicon-32x32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/favicon-32x32.png -------------------------------------------------------------------------------- /docs/.vuepress/public/ibax-eco.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/ibax-eco.png -------------------------------------------------------------------------------- /docs/.vuepress/public/ibax.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/ibax.ico -------------------------------------------------------------------------------- /docs/.vuepress/public/ibax.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/IBAX-io/documentation/7ae2041a86514c763a1fef190e985b8625f5d1fd/docs/.vuepress/public/ibax.png -------------------------------------------------------------------------------- /docs/.vuepress/public/manifest.webmanifest: -------------------------------------------------------------------------------- 1 | { 2 | "name": "IBAX", 3 | "short_name": "IBAX", 4 | "icons": [ 5 | { 6 | "src": "/android-chrome-192x192.png", 7 | "sizes": "192x192", 8 | "type": "image/png" 9 | }, 10 | { 11 | "src": "/android-chrome-512x512.png", 12 | "sizes": "512x512", 13 | "type": "image/png" 14 | } 15 | ], 16 | "theme_color": "#ffffff", 17 | "background_color": "#ffffff", 18 | "display": "standalone" 19 | } 20 | -------------------------------------------------------------------------------- /docs/.vuepress/styles/ebook.css: -------------------------------------------------------------------------------- 1 | /* GitHub stylesheet for MarkdownPad (http://markdownpad.com) */ 2 | /* Author: Nicolas Hery - http://nicolashery.com */ 3 | /* Version: b13fe65ca28d2e568c6ed5d7f06581183df8f2ff */ 4 | /* Source: https://github.com/nicolahery/markdownpad-github */ 5 | 6 | /* RESET 7 | =============================================================================*/ 8 | 9 | html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, embed, figure, figcaption, footer, header, hgroup, menu, nav, output, ruby, section, summary, time, mark, audio, video { 10 | margin: 0; 11 | padding: 0; 12 | border: 0; 13 | } 14 | 15 | /* BODY 16 | =============================================================================*/ 17 | 18 | body { 19 | font-family: Helvetica, arial, freesans, clean, sans-serif; 20 | font-size: 14px; 21 | line-height: 1.6; 22 | color: #333; 23 | background-color: #fff; 24 | padding: 20px; 25 | max-width: 960px; 26 | margin: 0 auto; 27 | } 28 | 29 | body>*:first-child { 30 | margin-top: 0 !important; 31 | } 32 | 33 | body>*:last-child { 34 | margin-bottom: 0 !important; 35 | } 36 | 37 | /* BLOCKS 38 | =============================================================================*/ 39 | 40 | p, blockquote, ul, ol, dl, table, pre { 41 | margin: 15px 0; 42 | } 43 | 44 | /* HEADERS 45 | =============================================================================*/ 46 | 47 | h1, h2, h3, h4, h5, h6 { 48 | margin: 20px 0 10px; 49 | padding: 0; 50 | font-weight: bold; 51 | -webkit-font-smoothing: antialiased; 52 | } 53 | 54 | h1 tt, h1 code, h2 tt, h2 code, h3 tt, h3 code, h4 tt, h4 code, h5 tt, h5 code, h6 tt, h6 code { 55 | font-size: inherit; 56 | } 57 | 58 | h1 { 59 | font-size: 24px; 60 | border-bottom: 1px solid #ccc; 61 | color: #000; 62 | } 63 | 64 | h2 { 65 | font-size: 18px; 66 | color: #000; 67 | } 68 | 69 | h3 { 70 | font-size: 14px; 71 | } 72 | 73 | h4 { 74 | font-size: 14px; 75 | } 76 | 77 | h5 { 78 | font-size: 14px; 79 | } 80 | 81 | h6 { 82 | color: #777; 83 | font-size: 14px; 84 | } 85 | 86 | body>h2:first-child, body>h1:first-child, body>h1:first-child+h2, body>h3:first-child, body>h4:first-child, body>h5:first-child, body>h6:first-child { 87 | margin-top: 0; 88 | padding-top: 0; 89 | } 90 | 91 | a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6 { 92 | margin-top: 0; 93 | padding-top: 0; 94 | } 95 | 96 | h1+p, h2+p, h3+p, h4+p, h5+p, h6+p { 97 | margin-top: 10px; 98 | } 99 | 100 | /* LINKS 101 | =============================================================================*/ 102 | 103 | a { 104 | color: #4183C4; 105 | text-decoration: none; 106 | } 107 | 108 | a:hover { 109 | text-decoration: underline; 110 | } 111 | 112 | /* LISTS 113 | =============================================================================*/ 114 | 115 | ul, ol { 116 | padding-left: 30px; 117 | } 118 | 119 | ul li > :first-child, 120 | ol li > :first-child, 121 | ul li ul:first-of-type, 122 | ol li ol:first-of-type, 123 | ul li ol:first-of-type, 124 | ol li ul:first-of-type { 125 | margin-top: 0px; 126 | } 127 | 128 | ul ul, ul ol, ol ol, ol ul { 129 | margin-bottom: 0; 130 | } 131 | 132 | dl { 133 | padding: 0; 134 | } 135 | 136 | dl dt { 137 | font-size: 14px; 138 | font-weight: bold; 139 | font-style: italic; 140 | padding: 0; 141 | margin: 15px 0 5px; 142 | } 143 | 144 | dl dt:first-child { 145 | padding: 0; 146 | } 147 | 148 | dl dt>:first-child { 149 | margin-top: 0px; 150 | } 151 | 152 | dl dt>:last-child { 153 | margin-bottom: 0px; 154 | } 155 | 156 | dl dd { 157 | margin: 0 0 15px; 158 | padding: 0 15px; 159 | } 160 | 161 | dl dd>:first-child { 162 | margin-top: 0px; 163 | } 164 | 165 | dl dd>:last-child { 166 | margin-bottom: 0px; 167 | } 168 | 169 | /* CODE 170 | =============================================================================*/ 171 | 172 | pre, code, tt { 173 | font-size: 12px; 174 | font-family: Consolas, "Liberation Mono", Courier, monospace; 175 | } 176 | 177 | code, tt { 178 | margin: 0 0px; 179 | padding: 0px 0px; 180 | white-space: nowrap; 181 | border: 1px solid #eaeaea; 182 | background-color: #f8f8f8; 183 | border-radius: 3px; 184 | } 185 | 186 | pre>code { 187 | margin: 0; 188 | padding: 0; 189 | white-space: pre; 190 | border: none; 191 | background: transparent; 192 | } 193 | 194 | pre { 195 | background-color: #f8f8f8; 196 | border: 1px solid #ccc; 197 | font-size: 13px; 198 | line-height: 19px; 199 | overflow: auto; 200 | padding: 6px 10px; 201 | border-radius: 3px; 202 | } 203 | 204 | pre code, pre tt { 205 | background-color: transparent; 206 | border: none; 207 | } 208 | 209 | kbd { 210 | -moz-border-bottom-colors: none; 211 | -moz-border-left-colors: none; 212 | -moz-border-right-colors: none; 213 | -moz-border-top-colors: none; 214 | background-color: #DDDDDD; 215 | background-image: linear-gradient(#F1F1F1, #DDDDDD); 216 | background-repeat: repeat-x; 217 | border-color: #DDDDDD #CCCCCC #CCCCCC #DDDDDD; 218 | border-image: none; 219 | border-radius: 2px 2px 2px 2px; 220 | border-style: solid; 221 | border-width: 1px; 222 | font-family: "Helvetica Neue",Helvetica,Arial,sans-serif; 223 | line-height: 10px; 224 | padding: 1px 4px; 225 | } 226 | 227 | /* QUOTES 228 | =============================================================================*/ 229 | 230 | blockquote { 231 | border-left: 4px solid #DDD; 232 | padding: 0 15px; 233 | color: #777; 234 | } 235 | 236 | blockquote>:first-child { 237 | margin-top: 0px; 238 | } 239 | 240 | blockquote>:last-child { 241 | margin-bottom: 0px; 242 | } 243 | 244 | /* HORIZONTAL RULES 245 | =============================================================================*/ 246 | 247 | hr { 248 | clear: both; 249 | margin: 15px 0; 250 | height: 0px; 251 | overflow: hidden; 252 | border: none; 253 | background: transparent; 254 | border-bottom: 4px solid #ddd; 255 | padding: 0; 256 | } 257 | 258 | /* TABLES 259 | =============================================================================*/ 260 | 261 | table th { 262 | font-weight: bold; 263 | } 264 | 265 | table th, table td { 266 | border: 1px solid #ccc; 267 | padding: 6px 13px; 268 | } 269 | 270 | table tr { 271 | border-top: 1px solid #ccc; 272 | background-color: #fff; 273 | } 274 | 275 | table tr:nth-child(2n) { 276 | background-color: #f8f8f8; 277 | } 278 | 279 | /* IMAGES 280 | =============================================================================*/ 281 | 282 | img { 283 | max-width: 100% 284 | } -------------------------------------------------------------------------------- /docs/.vuepress/styles/index.styl: -------------------------------------------------------------------------------- 1 | div.theme-default-content:not(.custom) { 2 | max-width: 100%; 3 | } 4 | blockquote { 5 | color: #000; 6 | border-left: 4px solid #64b5f6; 7 | border-top: 1px solid #64b5f6; 8 | } 9 | .home .hero img { 10 | max-height 240px !important; 11 | } -------------------------------------------------------------------------------- /docs/.vuepress/styles/palette.styl: -------------------------------------------------------------------------------- 1 | $accentColor = #DB8BE7 2 | -------------------------------------------------------------------------------- /docs/.vuepress/styles/runoob.css: -------------------------------------------------------------------------------- 1 | .example_code { 2 | font-size: 12px; 3 | font-family: Consolas, "Liberation Mono", Courier, monospace; 4 | background-color: #f8f8f8; 5 | border: 1px solid #ccc; 6 | font-size: 13px; 7 | line-height: 19px; 8 | overflow: auto; 9 | padding: 6px 10px; 10 | border-radius: 3px; 11 | white-space: pre-wrap; 12 | } 13 | 14 | .example_code>code { 15 | margin: 0; 16 | padding: 0; 17 | white-space: pre; 18 | border: none; 19 | background: transparent; 20 | } 21 | 22 | .example_code code, .example_code tt { 23 | background-color: transparent; 24 | border: none; 25 | } 26 | 27 | .tryitbtn { 28 | display: none; 29 | } -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: A Decentralized Commercial Cross-Chain infrastructure Network 6 | actionText: Quick start → 7 | actionLink: /concepts/about-the-platform.md 8 | features: 9 | - title: A great reduction of blockchain application cost 10 | - title: An independently build physical ecosystem 11 | - title: Quick deployment of distributed servers, development and application environments 12 | - title: A diversified DApp Store and BaaS functionality 13 | - title: Actual service response in seconds 14 | - title: Cross-chain and cross-system data interaction 15 | - title: A new infrastructure network integrating public, alliance, and rivate chains 16 | - title: A customizable consensus mechanism 17 | - title: Separation of front end and back end to meet various encryption needs 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 06/19/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # IBAX Documentation 24 | 25 | 26 | ## Concept 27 | 28 | * [IBAX Overview](concepts/about-the-platform.md) 29 | * [The IBAX Network](concepts/blockchain-layers.md) 30 | * [Proof-of-Authority Consensus](concepts/consensus.md) 31 | * [Terms and Definitions](concepts/thesaurus.md) 32 | * [FAQ](concepts/faq.md) 33 | 34 | ## Tutorial 35 | 36 | * [Tutorial for application development](tutorials/app_tutorial.md) 37 | * [Development Tutorial](tutorials/tutorial.md) 38 | 39 | ## Guide 40 | 41 | * [Smart Contracts](topics/script.md) 42 | * [Template Language](topics/templates2.md) 43 | * [Compiler and Virtual Machine](topics/vm.md) 44 | * [Daemon](topics/daemons.md) 45 | 46 | ## Reference 47 | 48 | * [RESTful API](reference/api2.md) 49 | * [Platform Parameters](reference/platform-parameters.md) 50 | * [Server Configuration File](reference/backend-config.md) 51 | * [Synchronized Monitoring Tool](reference/desync_monitor.md) 52 | * [JSON-RPC Application Programming Interface](reference/json-rpc.md) 53 | 54 | ## Deployment 55 | 56 | * [Deployment of A IBAX Network](howtos/deployment.md) 57 | 58 | -------------------------------------------------------------------------------- /docs/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # The IBAX Network {#the-ibax-network} 2 | 3 | 4 | In this section, we will brief you how to use IBAX. 5 | 6 | - [The IBAX Network](#the-ibax-network) 7 | - [Application developers](#application-developers) 8 | - [ECOLIB members](#ecolib-members) 9 | - [ECOLIB applications and platform applications](#ecolib-applications-and-platform-applications) 10 | - [Underlying model](#underlying-model) 11 | - [Implementation](#implementation) 12 | 13 | 14 | 15 | If you are interested in the development, use or management of applications in IBAX, then you may not need to understand it at all. 16 | 17 | In IBAX, the blockchain and the blockchain network are hidden from ECOLIB members, administrators, and application developers. IBAX offers [RESTful API](../reference/api2.md) for all user groups, which provide a tamper-proof and distributed access to the **global state** of the blockchain. 18 | 19 | ## Application developers {#application-developers} 20 | 21 | In technical terms, the **global state** is a set of data, which is implemented via IBAX's database. From the perspective of application developers, an application interacts with the database by querying, inserting and updating tables. 22 | 23 | In IBAX, transactions are written into the blockchain by implementing various contracts. These transactions will call contract codes implemented by blockchain network nodes, which will update the global state (database) accordingly. 24 | 25 | For application developers, a contract is a function that data will be written to the database when it is implemented. Pages are like scripts and the page code is a set of page [template](../topics/templates2.md) functions, some of these functions display page elements, while other data comes from the database. Application developers do not need to understand what are transactions, block generation and consensus algorithms, just use it. 26 | 27 | ## ECOLIB members {#ecolib-members} 28 | 29 | Applications written by developers run in an environment called [ECOLIB](thesaurus.md#ecolib). An application usually serves a specific purpose and complete various tasks together with several other applications. 30 | 31 | A user must become a member of an ECOLIB if wants to access applications in it, and it can be a member of multiple different ECOLIBs at the same time. 32 | 33 | ECOLIB members can view and modify the database from application pages, just like filling out forms, clicking buttons and navigating pages in a common web application. 34 | 35 | ## ECOLIB applications and platform applications {#ecolib-applications-and-platform-applications} 36 | 37 | Applications may fall into **ECOLIB applications** and **platform applications**. 38 | 39 | > ECOLIB applications 40 | 41 | An ECOLIB application implements certain unique functions or business processes of an ECOLIB, but it is only available in that ECOLIB. 42 | 43 | > Platform applications 44 | 45 | A platform application is applicable to all ECOLIBs. Any application could be developed as a platform application. IBAX developers would provide platform applications that support the core functions for ECOLIB governance, such as voting, notification, and ECOLIB member role management. 46 | 47 | ## Underlying model {#underlying-model} 48 | 49 | > Definition of layers 50 | 51 | IBAX consists of several layers: 52 | 53 | * User interaction layer 54 | 55 | ECOLIB members interact with the application through pages and page elements. 56 | 57 | * Application layer 58 | 59 | Application developers interact with the global state (data tables) through contract codes and page codes. 60 | 61 | * Global state layer 62 | 63 | Update and synchronize the global state (database) based on operations written to the distributed ledger (blockchain) 64 | 65 | * Blockchain layer 66 | 67 | Update the distributed ledger with new blocks. Operations (transactions) saved in new blocks must be performed on the global state. 68 | 69 | * Node network layer 70 | 71 | It implemented the IBAX Network protocol, which distributes, verifies transactions and generates new blocks on the node network. Similarly, new blocks are distributed and verified by the node network. 72 | 73 | The distributed ledger of all nodes is kept in sync. If having conflicts in a node, the node will identify which blockchains are considered valid and invalid blockchains will be rolled back accordingly. 74 | 75 | * Transaction layer 76 | 77 | Transactions are the basis for generating blocks and blockchain protocols, and transactions themselves are the results of operations performed at the user interaction layer. Transactions are generated by Weaver. 78 | 79 | When a user or developer performs an operation such as clicking a button on a page or implement a contract from the code editor, Weaver will convert this operation into a transaction and send it to the network node connected to it. 80 | 81 | Therefore, the flow of transactions is as follows: 82 | 83 | * A user operation in a user page will become a transaction; 84 | * The transaction is contained in a block; 85 | * The block is included in the blockchain; 86 | * The change of operation will cause the global state of the blockchain to change, and such operation will be applied to the database; 87 | * Any database change will be reflected in the application. 88 | 89 | ## Implementation {#implementation} 90 | 91 | IBAX has two major components, i.e. server [go-ibax](https://github.com/IBAX-io/go-ibax) and Weaver [Source code](https://github.com/IBAX-io/weaver). 92 | 93 | Weaver: 94 | * Providing the user pages; 95 | 96 | * Providing the IDE for application development; 97 | 98 | * Storing public keys of user accounts and perform authorization; 99 | 100 | * Requesting database data from application pages and display application pages to users; 101 | 102 | * Sending transactions to the server through [REST APIs](../reference/api2.md); 103 | 104 | In order to automatically create transactions against user operations, Weaver will convert such operations into transactions when application developers implement a contract from the IDE. 105 | 106 | Server: 107 | 108 | * Keeping the global state (database) of the node; 109 | * Implementation of the blockchain protocol; 110 | * Implementation of contract codes in the IBAX [Virtual Machine](../topics/vm.md); 111 | * Implementation of page codes in the [Template Engine](../topics/templates2.md); 112 | * Implementation of [RESTful API](../reference/api2.md). 113 | -------------------------------------------------------------------------------- /docs/de/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: Ein dezentralisiertes kommerzielles kettenübergreifendes Infrastrukturnetzwerk 6 | actionText: Schnellstart → 7 | actionLink: /de/concepts/about-the-platform.html 8 | features: 9 | - title: Eine große Reduzierung der Blockchain-Anwendungskosten 10 | - title: Ein unabhängig aufgebautes physisches Ökosystem 11 | - title: Schnelle Bereitstellung von verteilten Servern, Entwicklungs- und Anwendungsumgebungen 12 | - title: Ein diversifizierter DApp Store und BaaS-Funktionalität 13 | - title: Tatsächliche Serviceantwort in Sekunden 14 | - title: Ketten- und systemübergreifende Dateninteraktion 15 | - title: Ein neues Infrastrukturnetzwerk, das öffentliche, Allianz- und private Ketten integriert 16 | - title: Ein anpassbarer Konsensmechanismus 17 | - title: Trennung von Front-End und Back-End, um verschiedene Verschlüsselungsanforderungen zu erfüllen 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 06/19/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # IBAX Dokumentation 24 | 25 | 26 | ## Konzept 27 | 28 | * [IBAX Überblick](concepts/about-the-platform.md) 29 | * [The IBAX Netzwerk](concepts/blockchain-layers.md) 30 | * [Konsens zum Nachweis der Autorität](concepts/consensus.md) 31 | * [Begriffe und Definitionen](concepts/thesaurus.md) 32 | * [FAQ](concepts/faq.md) 33 | 34 | ## Lernprogramm 35 | 36 | * [Tutorial für die Anwendungsentwicklung](tutorials/app_tutorial.md) 37 | * [Development Tutorial](tutorials/tutorial.md) 38 | 39 | ## Handbuch 40 | 41 | * [Intelligente Verträge](topics/script.md) 42 | * [Vorlagensprache](topics/templates2.md) 43 | * [Compiler und virtuelle Maschine](topics/vm.md) 44 | * [Dämon](topics/daemons.md) 45 | 46 | ## Referenz 47 | 48 | * [RESTful API](reference/api2.md) 49 | * [Plattformparameter](reference/platform-parameters.md) 50 | * [Server-Konfigurationsdatei](reference/backend-config.md) 51 | * [Synchronisiertes Überwachungstool](reference/desync_monitor.md) 52 | * [JSON-RPC Application Programming Interface](reference/json-rpc.md) 53 | 54 | ## Einsatz 55 | 56 | * [Bereitstellung von A IBAX Netzwerk](howtos/deployment.md) 57 | 58 | -------------------------------------------------------------------------------- /docs/de/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # The IBAX Netzwerk {#the-ibax-network} 2 | 3 | In diesem Abschnitt werden wir Sie in die Verwendung von IBAX einweisen. 4 | 5 | - [The IBAX Netzwerk](#the-ibax-network) 6 | - [Anwendungsentwickler](#application-developers) 7 | - [ECOLIB Mitglieder](#ecolib-members) 8 | - [ECOLIB Anwendungen und Plattformanwendungen](#ecolib-applications-and-platform-applications) 9 | - [Zugrunde liegendes Modell](#underlying-model) 10 | - [Implementierung](#implementation) 11 | 12 | 13 | 14 | 15 | 16 | Wenn Sie an der Entwicklung, Verwendung oder Verwaltung von Anwendungen in IBAX interessiert sind, müssen Sie es möglicherweise überhaupt nicht verstehen. 17 | 18 | In IBAX sind die Blockchain und das Blockchain-Netzwerk vor ECOLIB-Mitgliedern, Administratoren und Anwendungsentwicklern verborgen. IBAX bietet für alle Benutzergruppen [RESTful API](../reference/api2.md) an, die einen manipulationssicheren und verteilten Zugriff auf den **globalen Zustand** der Blockchain ermöglichen. 19 | 20 | ## Anwendungsentwickler {#application-developers} 21 | 22 | Technisch gesehen ist der **global state** ein Datensatz, der über die Datenbank von IBAX implementiert wird. Aus der Perspektive von Anwendungsentwicklern interagiert eine Anwendung mit der Datenbank, indem sie Tabellen abfragt, einfügt und aktualisiert. 23 | 24 | In IBAX werden Transaktionen in die Blockchain geschrieben, indem verschiedene Verträge implementiert werden. Diese Transaktionen rufen Vertragscodes auf, die von Blockchain-Netzwerkknoten implementiert werden, die den globalen Status (Datenbank) entsprechend aktualisieren. 25 | 26 | Für Anwendungsentwickler ist ein Vertrag eine Funktion, dass Daten bei der Implementierung in die Datenbank geschrieben werden. Seiten sind wie Skripte und der Seitencode ist ein Satz von Seitenfunktionen [template](../topics/templates2.md), einige dieser Funktionen zeigen Seitenelemente an, während andere Daten aus der Datenbank stammen. Anwendungsentwickler müssen nicht verstehen, was Transaktionen, Blockgenerierung und Konsensalgorithmen sind, verwenden Sie sie einfach. 27 | 28 | ## ECOLIB mitglieder {#ecolib-members} 29 | 30 | Von Entwicklern geschriebene Anwendungen werden in einer Umgebung namens [ECOLIB](thesaurus.md#ecolib) ausgeführt. Eine Anwendung dient in der Regel einem bestimmten Zweck und erledigt zusammen mit mehreren anderen Anwendungen verschiedene Aufgaben. 31 | 32 | Ein Benutzer muss Mitglied einer ECOLIB werden, wenn er auf Anwendungen darin zugreifen möchte, und er kann gleichzeitig Mitglied mehrerer verschiedener ECOLIBs sein. 33 | 34 | ECOLIB-Mitglieder können die Datenbank von den Anwendungsseiten aus anzeigen und ändern, genau wie das Ausfüllen von Formularen, das Klicken auf Schaltflächen und das Navigieren durch Seiten in einer gemeinsamen Webanwendung. 35 | 36 | ## ECOLIB Anwendungen und Plattformanwendungen {#ecolib-applications-and-platform-applications} 37 | 38 | Anwendungen können in **ECOLIB-Anwendungen** und **Plattformanwendungen** fallen. 39 | 40 | ECOLIB-Anwendungen 41 | 42 | Eine ECOLIB-Anwendung implementiert bestimmte einzigartige Funktionen oder Geschäftsprozesse einer ECOLIB, ist aber nur in dieser ECOLIB verfügbar. 43 | Plattformanwendungen 44 | 45 | Eine Plattformanwendung gilt für alle ECOLIBs. Jede Anwendung könnte als Plattformanwendung entwickelt werden. IBAX-Entwickler würden Plattformanwendungen bereitstellen, die die Kernfunktionen für ECOLIB-Governance unterstützen, wie z. B. Abstimmung, Benachrichtigung und ECOLIB-Mitgliederrollenverwaltung. 46 | 47 | ## Liegendes Modell {#underlying-model} 48 | 49 | Definition von Schichten 50 | 51 | IBAX besteht aus mehreren Schichten: 52 | 53 | * Benutzerinteraktionsebene 54 | 55 | ECOLIB-Mitglieder interagieren mit der Anwendung über Seiten und Seitenelemente. 56 | 57 | * Anwendungsschicht 58 | 59 | Anwendungsentwickler interagieren mit dem globalen Zustand (Datentabellen) über Vertragscodes und Seitencodes. 60 | 61 | * Globale Zustandsebene 62 | 63 | Aktualisieren und synchronisieren Sie den globalen Status (Datenbank) basierend auf Operationen, die in das verteilte Ledger (Blockchain) geschrieben wurden. 64 | * Blockchain-Schicht 65 | 66 | Aktualisieren Sie das Distributed Ledger mit neuen Blöcken. Operationen (Transaktionen), die in neuen Blöcken gespeichert werden, müssen auf dem globalen Zustand durchgeführt werden. 67 | 68 | * Knotennetzwerkschicht 69 | 70 | Es implementierte das IBAX-Netzwerkprotokoll, das Transaktionen verteilt, verifiziert und neue Blöcke im Knotennetzwerk generiert. In ähnlicher Weise werden neue Blöcke vom Knotennetzwerk verteilt und verifiziert. 71 | 72 | Das verteilte Hauptbuch aller Knoten wird synchron gehalten. Wenn Konflikte in einem Knoten auftreten, identifiziert der Knoten, welche Blockchains als gültig gelten, und ungültige Blockchains werden entsprechend zurückgesetzt. 73 | 74 | * Transaktionsschicht 75 | 76 | Transaktionen sind die Grundlage für die Generierung von Blöcken und Blockchain-Protokollen, und Transaktionen selbst sind die Ergebnisse von Operationen, die auf der Benutzerinteraktionsebene ausgeführt werden. Transaktionen werden von Weaver generiert. 77 | 78 | Wenn ein Benutzer oder Entwickler eine Operation durchführt, z. B. das Klicken auf eine Schaltfläche auf einer Seite oder das Implementieren eines Vertrags aus dem Code-Editor, wandelt Weaver diese Operation in eine Transaktion um und sendet sie an den damit verbundenen Netzwerkknoten. 79 | Daher ist der Transaktionsfluss wie folgt: 80 | 81 | * Eine Benutzeroperation auf einer Benutzerseite wird zu einer Transaktion; 82 | * Die Transaktion ist in einem Block enthalten; 83 | 84 | * Der Block ist in der Blockchain enthalten; 85 | 86 | * Die Änderung der Operation bewirkt, dass sich der globale Zustand der Blockchain ändert, und diese Operation wird auf die Datenbank angewendet. 87 | 88 | * Jede Datenbankänderung wird in der Anwendung widergespiegelt. 89 | ## Implementierung {#implementation} 90 | 91 | IBAX besteht aus zwei Hauptkomponenten, nämlich Server [go-ibax](https://github.com/IBAX-io/go-ibax) und Weaver [Quellcode](https://github.com/IBAX-io/weaver ). 92 | 93 | Weber: 94 | * Bereitstellung der Benutzerseiten; 95 | * Bereitstellung der IDE für die Anwendungsentwicklung; 96 | * Speichern öffentlicher Schlüssel von Benutzerkonten und Ausführen der Autorisierung; 97 | * Anfordern von Datenbankdaten von Anwendungsseiten und Anzeigen von Anwendungsseiten für Benutzer; 98 | * Senden von Transaktionen an den Server über [REST APIs](../reference/api2.md); 99 | 100 | Um automatisch Transaktionen für Benutzeroperationen zu erstellen, wandelt Weaver solche Operationen in Transaktionen um, wenn Anwendungsentwickler einen Vertrag von der IDE implementieren. 101 | 102 | Server: 103 | * Halten des globalen Zustands (Datenbank) des Knotens; 104 | * Implementierung des Blockchain-Protokolls; 105 | * Implementierung von Vertragscodes in der IBAX [Virtual Machine](../topics/vm.md); 106 | * Implementierung von Seitencodes in der [Template Engine](../topics/templates2.md); 107 | * Implementierung von [RESTful API](../reference/api2.md). -------------------------------------------------------------------------------- /docs/de/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # Serverkonfigurationsdatei {#server-configuration-file} 2 | 3 | In diesem Abschnitt stellen wir Parameter in der Serverkonfigurationsdatei vor. 4 | ## Einführung in die Serverkonfigurationsdatei {#introduction-to-the-server-configuration-file} 5 | 6 | Die Serverkonfigurationsdatei definiert die Knotenkonfiguration von IBAX. 7 | ## Standort {#location} 8 | 9 | Diese Datei befindet sich im Arbeitsverzeichnis des Servers und heißt `config.toml`. 10 | ## Abschnitte {#sections} 11 | 12 | Die Konfigurationsdatei besteht aus den folgenden Abschnitten: 13 | 14 | > Allgemeiner Teil 15 | 16 | Es definiert das Arbeitsverzeichnis DataDir, das erste Blockverzeichnis FirstBlockPath und andere Parameter. 17 | 18 | > [TCP-Server] 19 | 20 | Es definiert die TCP-Dienstparameter. 21 | 22 | TCPServer wird für die Netzwerkinteraktion zwischen Knoten verwendet. 23 | > [HTTP] 24 | 25 | Es definiert die HTTP-Dienstparameter. 26 | 27 | HTTPServer bietet RESTful-APIs. 28 | 29 | > [DB] 30 | 31 | Es definiert Parameter der PostgreSQL-Knotendatenbank. 32 | 33 | > [StatistikD] 34 | 35 | Es definiert Parameter des Kollektors StatsD für die Knotenbetriebsanzeige. 36 | 37 | > [Zentrifuge] 38 | 39 | Es definiert Parameter des Benachrichtigungsdienstes Centrifugo. 40 | 41 | > [Protokoll] 42 | 43 | Es definiert Parameter des Protokolldienstes Log. 44 | 45 | > [TokenBewegung] 46 | 47 | Es definiert Parameter des Token-Zirkulationsdienstes TokenMovement. 48 | 49 | ## Eine Beispielkonfigurationsdatei {#an-example-configuration-file} 50 | 51 | ``` 52 | PidFilePath = "/IBAX-data/go-ibax.pid" 53 | LockFilePath = "/IBAX-data/go-ibax.lock" 54 | DataDir = "/IBAX-data" 55 | KeysDir = "/IBAX-data" 56 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/IBAX-temp" 57 | FirstBlockPath = "/IBAX-data/1block" 58 | TLS = false 59 | TLSCert = "" 60 | TLSKey = "" 61 | OBSMode = "none" 62 | HTTPServerMaxBodySize = 1048576 63 | MaxPageGenerationTime = 3000 64 | NodesAddr = [] 65 | 66 | [TCPServer] 67 | Host = "127.0.0.1" 68 | Port = 7078 69 | 70 | [HTTP] 71 | Host = "127.0.0.1" 72 | Port = 7079 73 | 74 | [DB] 75 | Name = "IBAX" 76 | Host = "127.0.0.1" 77 | Port = 5432 78 | User = "postgres" 79 | Password = "123456" 80 | LockTimeout = 5000 81 | 82 | [StatsD] 83 | Host = "127.0.0.1" 84 | Port = 8125 85 | Name = "IBAX" 86 | 87 | [Centrifugo] 88 | Secret = "127.0.0.1" 89 | URL = "127.0.0.1" 90 | 91 | [Log] 92 | LogTo = "stdout" 93 | LogLevel = "ERROR" 94 | LogFormat = "text" 95 | [Log.Syslog] 96 | Facility = "kern" 97 | Tag = "go-ibax" 98 | 99 | [TokenMovement] 100 | Host = "" 101 | Port = 0 102 | Username = "" 103 | Password = "" 104 | To = "" 105 | From = "" 106 | Subject = "" 107 | ``` 108 | -------------------------------------------------------------------------------- /docs/de/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # Synchronisiertes Überwachungstool {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor ist ein spezielles Tool, mit dem überprüft werden kann, ob die Datenbank auf dem angegebenen Knoten synchronisiert wurde. 4 | 5 | Das Tool kann als Daemon verwendet oder für eine einmalige Überprüfung gestartet werden. 6 | 7 | Das Funktionsprinzip des Tools basiert auf Folgendem: 8 | 9 | 1.Jeder Block enthält den Hash aller Änderungen aller Transaktionen, fordern Sie den angegebenen Knoten auf, seine letzte Block-ID bereitzustellen; 10 | 2. Fordern Sie dann einen Block mit dieser ID von allen Knoten an und vergleichen Sie die obigen Hashes; 11 | 3.Wenn die Hashes unterschiedlich sind, wird eine Synchronisierungsfehlermeldung an die im Befehl angegebene E-Mail-Adresse gesendet. 12 | 13 | ## Standort {#location} 14 | 15 | Das Tool befindet sich im Verzeichnis `tools/desync_monitor/`. 16 | 17 | # Befehlszeilen-Flags {#command-prompt-flags} 18 | Die folgenden Flags können von der Eingabeaufforderung aus verwendet werden: 19 | * confPath - Pfad der Konfigurationsdatei. Der Standarddateiname ist `config.toml`; 20 | * nodesList - Knotenliste des angeforderten Blocks, getrennt durch Kommas. Der Standardwert ist `127.0.0.1:7079`; 21 | * daemonMode - Wird als Daemon gestartet und sollte verwendet werden, wenn alle N Sekunden eine Authentifizierung erforderlich ist. Dieses Flag ist standardmäßig auf `false` gesetzt; 22 | * queryingPeriod - Wenn das Tool als Daemon gestartet wird, legt dieser Parameter das Zeitintervall (in Sekunden) zwischen den Prüfungen fest, standardmäßig "`1` Sekunde. 23 | * alertMessageTo – Die E-Mail-Adresse, an die Synchronisierungswarnfehler gesendet werden. 24 | * alertMessageSubj - Betreff der Nachricht in der Warnmeldung, standardmäßig das Problem der `node synchronization`; 25 | * alertMessageFrom - Adresse, an die die Nachricht gesendet wurde. 26 | * smtpHost - SMTP-Server-Host, der zum Senden von E-Mails verwendet wird, standardmäßig `""`; 27 | * smtpPort - SMTP-Serverport, der zum Senden von E-Mail-Nachrichten verwendet wird, standardmäßig `25`; 28 | * smtpUsername - Benutzername des SMTP-Servers, standardmäßig `""`; 29 | * smtpPassword - SMTP-Serverpasswort, standardmäßig `""`. 30 | 31 | ## Aufbau {#configuration} 32 | Das Tool verwendet eine Konfigurationsdatei im toml-Format. 33 | 34 | Standardmäßig sucht es nach der Datei config.toml in dem Ordner, in dem die Binärdatei gestartet werden soll. 35 | 36 | Der Dateipfad kann mit dem Flag configPath geändert werden. 37 | 38 | ``` 39 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 40 | 41 | [daemon] 42 | daemon = false 43 | querying_period = 1 44 | 45 | [alert_message] 46 | to = "" 47 | subject = "problem with xxx nodes" 48 | from = "" 49 | 50 | [smtp] 51 | host = "" 52 | port = 25 53 | username = "" 54 | password = "" 55 | ``` 56 | ### nodes_list {#nodes-list} 57 | * nodes_list - Liste der Knoten (Hosts), die Informationen anfordern. 58 | 59 | ### [daemon] {#daemon} 60 | Konfiguration des Daemon-Modus. 61 | * daemon_mode – Ein Tool arbeitet als Daemon und führt Synchronisationsprüfungen durch. 62 | * querying_period - Zeitintervall zwischen Synchronisationsprüfungen. 63 | 64 | ### [alert_message] {#alert-message} 65 | Warnmeldungsparameter. 66 | * an - E-Mail-Adresse des Empfängers von Synchronisierungsfehler-Warnmeldungen; 67 | * Betreff - Betreff der Nachricht; 68 | * von - E-Mail des Absenders. 69 | 70 | ### [smtp] {#smtp} 71 | SMTP-Serverparameter (Simple Mail Transfer Protocol), die zum Senden von Synchronisierungsfehlermeldungen verwendet werden. 72 | * Host – SMTP-Serverschlauch; 73 | * port – SMTP-Server-Port; 74 | * Benutzername – Benutzername des SMTP-Servers; 75 | * Passwort – Passwort des SMTP-Servers; 76 | -------------------------------------------------------------------------------- /docs/es/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: Una red de infraestructura comercial descentralizada entre cadenas 6 | actionText: Inicio rápido → 7 | actionLink: /es/concepts/about-the-platform.html 8 | features: 9 | - title: Una gran reducción del costo de la aplicación blockchain. 10 | - title: Un ecosistema físico construido de forma independiente 11 | - title: Implementación rápida de servidores distribuidos, entornos de desarrollo y aplicaciones 12 | - title: Una tienda DApp diversificada y una funcionalidad BaaS 13 | - title: Respuesta de servicio real en segundos 14 | - title: Interacción de datos entre cadenas y sistemas 15 | - title: Una nueva red de infraestructura que integra cadenas públicas, de alianzas y privadas. 16 | - title: Mecanismo de consenso personalizable 17 | - title: Separación de los extremos frontal y posterior para satisfacer diversas necesidades de cifrado 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 07/04/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # Documentación IBAX 24 | 25 | 26 | ## Concepto 27 | 28 | * [Descripción de la plataforma blockchain IBAX](concepts/about-the-platform.md) 29 | * [La plataforma de blockchain IBAX](concepts/blockchain-layers.md) 30 | * [Consenso de prueba de autoridad descentralizado](concepts/consensus.md) 31 | * [Terminología y definiciones](concepts/thesaurus.md) 32 | * [Preguntas frecuentes](concepts/faq.md) 33 | 34 | ## Tutorial 35 | 36 | * [Tutorial de desarrollo de aplicaciones](tutorials/app_tutorial.md) 37 | * [Tutorial para desarrolladores de redes IBAX](tutorials/tutorial.md) 38 | 39 | ## Guía 40 | 41 | * [Contratos inteligentes](topics/script.md) 42 | * [Lenguaje de plantillas](topics/templates2.md) 43 | * [Compilador y máquina virtual](topics/vm.md) 44 | * [Demonio](topics/daemons.md) 45 | 46 | ## Referirse a 47 | 48 | * [API RESTful v2](reference/api2.md) 49 | * [Parámetros de la plataforma](reference/platform-parameters.md) 50 | * [Archivo de configuración del servidor](reference/backend-config.md) 51 | * [Herramienta de monitoreo sincronizado](reference/desync_monitor.md) 52 | * [Interfaz de programación de aplicaciones JSON-RPC](reference/json-rpc.md) 53 | 54 | ## Desplegar 55 | 56 | * [Despliegue de la plataforma IBAX Blockchain y la red IBAX](howtos/deployment.md) 57 | 58 | -------------------------------------------------------------------------------- /docs/es/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # La plataforma de blockchain IBAX {#the-ibax-network} 2 | 3 | 4 | - [La plataforma de blockchain IBAX](#the-ibax-network) 5 | - [Desarrolladores de aplicaciones](#application-developers) 6 | - [Miembros del ecosistema](#ecolib-members) 7 | - [Aplicaciones del ecosistema y aplicaciones de plataforma](#ecolib-applications-and-platform-applications) 8 | - [Modelo subyacente](#underlying-model) 9 | - [Implementación](#implementation) 10 | 11 | 12 | 13 | Este capítulo explica cómo utilizar la plataforma blockchain IBAX. 14 | 15 | Si está interesado en desarrollar y gestionar el ecosistema de aplicaciones en la plataforma blockchain IBAX, es posible que no necesite saber nada sobre la blockchain y la red blockchain. 16 | En la plataforma blockchain IBAX, la blockchain y la red blockchain están ocultas para los miembros del ecosistema, los administradores y los desarrolladores de aplicaciones. 17 | La plataforma blockchain IBAX ha proporcionado interfaces [RESTful API](../reference/api2.md) para todos estos grupos de usuarios. Estas interfaces proporcionan acceso al estado global distribuido resistente a la manipulación de la blockchain. 18 | 19 | ## Desarrolladores de aplicaciones {#application-developers} 20 | 21 | En términos técnicos, el **estado global** es un conjunto de datos. La implementación del estado global de la plataforma blockchain IBAX es una base de datos. 22 | Desde la perspectiva de los desarrolladores de aplicaciones, las aplicaciones interactúan con la base de datos mediante consultas, inserciones y actualizaciones de tablas de la base de datos. 23 | 24 | En la plataforma blockchain IBAX, las transacciones se escriben en la blockchain mediante la ejecución de contratos, que llaman al código de contrato ejecutado por los nodos de la red blockchain, lo que cambia la base de datos de estado global. 25 | 26 | Para los desarrolladores de aplicaciones, los contratos son funciones que escriben datos en la base de datos cuando se ejecutan. Las páginas son como scripts. 27 | El código de la página es un conjunto de funciones de [plantilla de página](../topics/templates2.md). Algunas de estas funciones muestran elementos de la página, mientras que otras recuperan datos de la base de datos. 28 | Los desarrolladores de aplicaciones pueden utilizar la plataforma blockchain IBAX sin conocer las transacciones, la generación de bloques y los algoritmos de consenso. 29 | 30 | ## Miembros del ecosistema {#ecolib-members} 31 | 32 | Las aplicaciones escritas por los desarrolladores de aplicaciones funcionan en el entorno del [ecosistema](../concepts/thesaurus.md#ecosystem), que generalmente sirve a un propósito específico y combina diferentes aspectos de las aplicaciones para lograr ese propósito. 33 | 34 | Para acceder a las aplicaciones en el ecosistema, los usuarios deben convertirse en miembros del ecosistema. Un usuario puede ser miembro de múltiples ecosistemas. 35 | 36 | Los miembros del ecosistema pueden ver y modificar la base de datos desde las páginas de la aplicación, al igual que en las aplicaciones web comunes, completar formularios, hacer clic en botones y navegar por las páginas. 37 | 38 | ## Aplicaciones de Ecosistema y Aplicaciones de Plataforma {#ecolib-aplicaciones-y-aplicaciones-de-plataforma} 39 | 40 | Las aplicaciones se pueden dividir en dos categorías: **Aplicaciones de Ecosistema** y **Aplicaciones de Plataforma**. 41 | 42 | > Aplicaciones de Ecosistema 43 | 44 | Las aplicaciones de ecosistema implementan funciones o procesos de negocio exclusivos de ese ecosistema. Las aplicaciones de ecosistema solo están disponibles dentro de su ecosistema. 45 | 46 | > Aplicaciones de Plataforma 47 | 48 | Las aplicaciones de plataforma son aplicables a todos los ecosistemas. Cualquier aplicación puede desarrollarse como una aplicación de plataforma. Los desarrolladores de la plataforma de blockchain IBAX proporcionan aplicaciones de plataforma que admiten funciones centrales de gobernanza del ecosistema, como votación, notificación y gestión de roles de miembros del ecosistema. 49 | 50 | ## Modelo Subyacente {#underlying-model} 51 | 52 | > Definición de niveles 53 | 54 | La plataforma de blockchain IBAX se divide en varios niveles: 55 | 56 | > - Capa de Interacción de Usuario 57 | > 58 | > > Los miembros del ecosistema interactúan con la aplicación a través de páginas y elementos de página. 59 | > 60 | > - Capa de Aplicación 61 | > 62 | > > Los desarrolladores de aplicaciones interactúan con el estado global (tabla de base de datos) a través de código de contrato y código de página. 63 | > 64 | > - Capa de Estado Global 65 | > 66 | > > Actualiza y sincroniza el estado global (base de datos) según las operaciones de escritura en el libro mayor de operaciones distribuido (blockchain). 67 | > 68 | > - Capa de Blockchain 69 | > 70 | > > Actualiza el libro mayor de operaciones distribuido utilizando nuevos bloques. Las operaciones (transacciones) guardadas en los nuevos bloques deben ejecutarse en el estado global. 71 | > 72 | > - Capa de Red de Nodos 73 | > 74 | > > Implementa el protocolo de red de la plataforma de blockchain IBAX. El protocolo de red distribuye transacciones, verifica transacciones y genera nuevos bloques en la red de nodos. De manera similar, los nuevos bloques se distribuyen y verifican en la red de nodos. 75 | > > 76 | > > El libro mayor de operaciones distribuido de todos los nodos se mantiene sincronizado. Si hay conflictos entre los nodos, los nodos identificarán qué blockchain se considera una cadena válida y revertirán la cadena no válida. 77 | > 78 | > - Capa de Transacciones 79 | > 80 | > La transacción es la base para generar bloques y el protocolo de la cadena de bloques, la transacción en sí es el resultado de una operación ejecutada en la capa de interacción del usuario. La transacción es generada por Weaver. 81 | 82 | Cuando el usuario o el desarrollador realiza una operación, como hacer clic en un botón en la página o ejecutar un contrato desde el editor de código, Weaver convierte esta operación en una transacción y la envía a los nodos de la red a la que está conectado. 83 | 84 | Por lo tanto, el flujo de la transacción es el siguiente: 85 | 86 | - La operación del usuario en la página crea una transacción; 87 | - Esta transacción se incluye en un bloque; 88 | - Este bloque se incluye en la cadena de bloques; 89 | - El cambio en la operación provoca un cambio en el estado global de la cadena de bloques, que se aplica a la base de datos; 90 | - Los cambios en la base de datos se muestran en la aplicación. 91 | 92 | ## Implementación {#implementation} 93 | 94 | Los dos componentes principales de la plataforma de blockchain IBAX son el servidor [go-ibax](https://github.com/IBAX-io/go-ibax) y el código fuente de [Weaver](https://github.com/IBAX-io/weaver). 95 | 96 | Weaver: 97 | > - Proporciona la página de usuario; 98 | > 99 | > - Proporciona un IDE para el desarrollo de aplicaciones; 100 | > 101 | > - Almacena la clave pública de la cuenta del usuario y realiza la autorización; 102 | > 103 | > - Solicita datos de la base de datos desde la página de la aplicación y muestra la página de la aplicación al usuario; 104 | > 105 | > - Envía transacciones al servidor a través de [REST API](../reference/api2.md); 106 | > 107 | > > Para facilitar la operación del usuario, Weaver crea automáticamente transacciones. Cuando los desarrolladores de aplicaciones ejecutan un contrato desde el IDE, Weaver convierte esa operación en una transacción. 108 | 109 | Servidor: 110 | > - Mantiene el estado global del nodo (base de datos); 111 | - Implementar el protocolo de blockchain; 112 | - Ejecutar código de contrato en una [máquina virtual](../topics/vm.md); 113 | - Ejecutar código de página en un [motor de plantillas](../topics/templates2.md); 114 | - Implementar una interfaz [RESTful API](../reference/api2.md). 115 | -------------------------------------------------------------------------------- /docs/es/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # Archivo de configuración del servidor {#server-configuration-file} 2 | 3 | Esta sección describe los parámetros del archivo de configuración del servidor. 4 | 5 | ## Introducción al archivo de configuración del servidor {#introduction-to-the-server-configuration-file} 6 | 7 | El archivo de configuración del servidor define la configuración del nodo de la plataforma de blockchain IBAX. 8 | 9 | ## Ubicación {#location} 10 | 11 | Este archivo se encuentra en el directorio de trabajo del servidor y se llama `config.toml`. 12 | 13 | ## Secciones {#sections} 14 | 15 | El archivo de configuración tiene las siguientes secciones: 16 | 17 | > Parte normal 18 | 19 | Se define el directorio de trabajo DataDir, la ruta del primer bloque FirstBlockPath y otros parámetros. 20 | 21 | > [TCPServer] 22 | 23 | Se definen los parámetros del servicio TCP. 24 | 25 | TCPServer se utiliza para la interacción de red entre nodos. 26 | 27 | > [HTTP] 28 | 29 | Se definen los parámetros del servicio HTTP. 30 | 31 | HTTPServer proporciona una API RESTful. 32 | 33 | > [DB] 34 | 35 | Se definen los parámetros de la base de datos del nodo PostgreSQL. 36 | 37 | > [StatsD] 38 | 39 | Se definen los parámetros del recolector de métricas de operación del nodo StatsD. 40 | 41 | > [Centrifugo] 42 | 43 | Se definen los parámetros del servicio de notificación Centrifugo. 44 | 45 | > [Log] 46 | 47 | Se definen los parámetros del servicio de registro Log. 48 | 49 | > [TokenMovement] 50 | 51 | Se definen los parámetros del servicio de circulación de tokens TokenMovement. 52 | 53 | ## Ejemplo de archivo de configuración {#an-example-configuration-file} 54 | 55 | ``` js 56 | PidFilePath = "/ibax-data/go-ibax.pid" 57 | LockFilePath = "/ibax-data/go-ibax.lock" 58 | DataDir = "/ibax-data" 59 | KeysDir = "/ibax-data" 60 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/ibax-temp" 61 | FirstBlockPath = "/ibax-data/1block" 62 | TLS = false 63 | TLSCert = "" 64 | TLSKey = "" 65 | OBSMode = "none" 66 | HTTPServerMaxBodySize = 1048576 67 | MaxPageGenerationTime = 3000 68 | NodesAddr = [] 69 | 70 | [TCPServer] 71 | Host = "127.0.0.1" 72 | Port = 7078 73 | 74 | [HTTP] 75 | Host = "127.0.0.1" 76 | Port = 7079 77 | 78 | [DB] 79 | Name = "ibax" 80 | Host = "127.0.0.1" 81 | Port = 5432 82 | User = "postgres" 83 | Password = "123456" 84 | LockTimeout = 5000 85 | 86 | [StatsD] 87 | Host = "127.0.0.1" 88 | Port = 8125 89 | Name = "ibax" 90 | 91 | [Centrifugo] 92 | Secret = "127.0.0.1" 93 | URL = "127.0.0.1" 94 | 95 | [Log] 96 | LogTo = "stdout" 97 | LogLevel = "ERROR" 98 | LogFormat = "text" 99 | [Log.Syslog] 100 | Facility = "kern" 101 | Tag = "go-ibax" 102 | 103 | [TokenMovement] 104 | Host = "" 105 | Port = 0 106 | Username = "" 107 | Password = "" 108 | To = "" 109 | From = "" 110 | Subject = "" 111 | ``` 112 | -------------------------------------------------------------------------------- /docs/es/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # Herramienta de monitoreo sincronizado {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor es una herramienta especial que se utiliza para verificar si la base de datos en un nodo especificado está sincronizada. 4 | 5 | Esta herramienta se puede utilizar como un proceso en segundo plano o se puede iniciar para realizar una verificación única. 6 | 7 | El funcionamiento de esta herramienta se basa en lo siguiente: 8 | 9 | > 1. Cada bloque contiene el hash de todos los cambios de todas las transacciones. Se solicita al nodo especificado que proporcione su último ID de bloque. 10 | > 2. Luego, se solicitan bloques de todos los nodos que tienen ese ID y se comparan los hashes mencionados anteriormente. 11 | > 3. Si los hashes son diferentes, se enviará un mensaje de error de sincronización a la dirección de correo electrónico especificada en el comando. 12 | 13 | ## Ubicación {#location} 14 | 15 | Esta herramienta se encuentra en `tools/desync_monitor/`. 16 | 17 | ## Banderas del símbolo del sistema {#command-prompt-flags} 18 | 19 | Se pueden utilizar las siguientes banderas desde el símbolo del sistema: 20 | 21 | > - **confPath** -- Ruta al archivo de configuración. El nombre de archivo predeterminado es `config.toml`; 22 | > - **nodesList** -- Lista de nodos para solicitar bloques, separados por comas. El valor predeterminado es `127.0.0.1:7079`; 23 | > - **daemonMode** -- Iniciar como un demonio, debe usarse cuando se necesita verificar cada N segundos. Esta bandera está establecida en `false` de forma predeterminada; 24 | > - **queryingPeriod** -- Si la herramienta se inicia como un demonio, este parámetro establece el intervalo de tiempo (en segundos) entre comprobaciones. El valor predeterminado es `1` segundo. 25 | 26 | - **alertMessageTo** -- Dirección de correo electrónico a la que se enviarán las alertas de error de sincronización. 27 | 28 | > - **alertMessageSubj** -- Asunto del mensaje en el mensaje de alerta, el valor predeterminado es problema de sincronización del nodo; 29 | > - **alertMessageFrom** -- Dirección desde la que se envía el mensaje. 30 | > - **smtpHost** -- Host del servidor SMTP utilizado para enviar correos electrónicos, el valor predeterminado es `""`; 31 | > - **smtpPort** -- Puerto del servidor SMTP utilizado para enviar mensajes de correo electrónico, el valor predeterminado es `25`; 32 | > - **smtpUsername** -- Nombre de usuario del servidor SMTP, el valor predeterminado es `""`; 33 | > - **smtpPassword** -- Contraseña del servidor SMTP, el valor predeterminado es `""`. 34 | 35 | ## Configuración {#configuration} 36 | 37 | Esta herramienta utiliza un archivo de configuración en formato toml. 38 | 39 | Por defecto, buscará el archivo *config.toml* en la carpeta donde se inició el archivo binario. 40 | 41 | Puede cambiar la ruta del archivo utilizando la opción **configPath**. 42 | 43 | ```text 44 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 45 | 46 | [daemon] 47 | daemon = false 48 | querying_period = 1 49 | 50 | [alert_message] 51 | to = "" 52 | subject = "problem with xxx nodes" 53 | from = "" 54 | 55 | [smtp] 56 | host = "" 57 | port = 25 58 | username = "" 59 | password = "" 60 | ``` 61 | 62 | ### nodes_list {#nodes-list} 63 | 64 | > - **nodes_list** - Lista de nodos (hosts) que solicitan información. 65 | 66 | ### [daemon] {#daemon} 67 | 68 | Configuración del modo de proceso de demonio. 69 | 70 | > - **daemon_mode** -- La herramienta funciona como un proceso de demonio y realiza comprobaciones de sincronización. 71 | > - **querying_period** -- El intervalo de tiempo entre las comprobaciones de sincronización. 72 | 73 | ### [alert_message] {#alert-message} 74 | 75 | Parámetros de mensaje de advertencia. 76 | 77 | > - **to** -- Dirección de correo electrónico del destinatario para el mensaje de advertencia sincrónico; 78 | > - **subject** -- Tema del mensaje; 79 | > - **from** -- Dirección de correo electrónico del remitente. 80 | 81 | ### [smtp] {#smtp} 82 | 83 | Parámetros del servidor de Protocolo de Transferencia de Correo Simple (Simple Mail Transfer Protocol, SMTP) para enviar mensajes de advertencia sincrónicos. 84 | 85 | > - **host** -- Servidor SMTP; 86 | > - **port** -- Puerto del servidor SMTP; 87 | > - **username** -- Nombre de usuario del servidor SMTP; 88 | > - **password** -- Contraseña del servidor SMTP; 89 | -------------------------------------------------------------------------------- /docs/fr/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: Un réseau d'infrastructures commerciales inter-chaînes décentralisées 6 | actionText: Démarrage rapide → 7 | actionLink: /fr/concepts/about-the-platform.html 8 | features: 9 | - title: Une grande réduction du coût de l'application blockchain 10 | - title: Un écosystème physique construit de manière indépendante 11 | - title: Déploiement rapide de serveurs distribués, d'environnements de développement et d'applications 12 | - title: Un DApp Store diversifié et des fonctionnalités BaaS 13 | - title: Réponse réelle du service en quelques secondes 14 | - title: Interaction des données inter-chaînes et inter-systèmes 15 | - title: Un nouveau réseau d'infrastructures intégrant des chaînes publiques, alliances et rives 16 | - title: Un mécanisme de consensus personnalisable 17 | - title: Séparation du front-end et du back-end pour répondre aux divers besoins de cryptage 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 07/05/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # Documentation IBAX 24 | 25 | 26 | ## Concept 27 | 28 | * [Aperçu d'IBAX](concepts/about-the-platform.md) 29 | * [Le réseau IBAX](concepts/blockchain-layers.md) 30 | * [Consensus de Preuve d'Autorité](concepts/consensus.md) 31 | * [Termes et Définitions](concepts/thesaurus.md) 32 | * [FAQ](concepts/faq.md) 33 | 34 | ## Tutoriel 35 | 36 | * [Tutoriel de développement d'application](tutorials/app_tutorial.md) 37 | * [Tutoriel de développement](tutorials/tutorial.md) 38 | 39 | ## Guide 40 | 41 | * [Contrats Intelligents](topics/script.md) 42 | * [Langage de Modèle](topics/templates2.md) 43 | * [Compilateur et Machine Virtuelle](topics/vm.md) 44 | * [Démon](topics/daemons.md) 45 | 46 | ## Référence 47 | 48 | * [API RESTful](reference/api2.md) 49 | * [Paramètres de la Plateforme](reference/platform-parameters.md) 50 | * [Fichier de Configuration du Serveur](reference/backend-config.md) 51 | * [Outil de Surveillance Synchronisée](reference/desync_monitor.md) 52 | * [Interface de Programmation d'Application JSON-RPC](reference/json-rpc.md) 53 | 54 | ## Déploiement 55 | 56 | * [Déploiement d'un Réseau IBAX](howtos/deployment.md) 57 | 58 | 59 | -------------------------------------------------------------------------------- /docs/fr/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # Le réseau IBAX {#the-ibax-network} 2 | 3 | Dans cette section, nous vous expliquerons comment utiliser IBAX. 4 | 5 | - [Le réseau IBAX](#the-ibax-network) 6 | - [Développeurs d'applications](#application-developers) 7 | - [Membres d'ECOLIB](#ecolib-members) 8 | - [Applications ECOLIB et applications de plateforme](#ecolib-applications-and-platform-applications) 9 | - [Modèle sous-jacent](#underlying-model) 10 | - [Mise en œuvre](#implementation) 11 | 12 | 13 | 14 | Si vous êtes intéressé par le développement, l'utilisation ou la gestion des applications dans IBAX, vous n'avez peut-être pas besoin de le comprendre du tout. 15 | 16 | Dans IBAX, la blockchain et le réseau blockchain sont cachés aux membres d'ECOLIB, aux administrateurs et aux développeurs d'applications. 17 | IBAX propose une [API RESTful](../reference/api2.md) pour tous les groupes d'utilisateurs, qui offre un accès distribué et inviolable à l'état global de la blockchain. 18 | 19 | ## Développeurs d'applications {#application-developers} 20 | 21 | En termes techniques, l'**état global** est un ensemble de données, qui est implémenté via la base de données d'IBAX. 22 | Du point de vue des développeurs d'applications, une application interagit avec la base de données en interrogeant, en insérant et en mettant à jour des tables. 23 | 24 | Dans IBAX, les transactions sont écrites dans la blockchain en implémentant divers contrats intelligents. Ces transactions appelleront des codes de contrat intelligent implémentés par les nœuds du réseau blockchain, qui mettront à jour l'état global (base de données) en conséquence. 25 | 26 | Pour les développeurs d'applications, un contrat intelligent est une fonction à laquelle des données seront écrites dans la base de données lorsqu'elle est implémentée. 27 | Les pages sont comme des scripts et le code de la page est un ensemble de fonctions de modèle de page, certaines de ces fonctions affichent des éléments de page, tandis que d'autres données proviennent de la base de données. 28 | Les développeurs d'applications n'ont pas besoin de comprendre ce que sont les transactions, la génération de blocs et les algorithmes de consensus, il suffit de les utiliser. 29 | 30 | ## Membres d'ECOLIB {#ecolib-members} 31 | 32 | Les applications écrites par les développeurs s'exécutent dans un environnement appelé [ECOLIB](thesaurus.md#ecolib). 33 | Une application sert généralement à un but spécifique et accomplit diverses tâches en collaboration avec plusieurs autres applications. 34 | 35 | Un utilisateur doit devenir membre d'un ECOLIB s'il souhaite accéder aux applications qui s'y trouvent, et il peut être membre de plusieurs ECOLIB différents en même temps. 36 | 37 | Les membres d'ECOLIB peuvent consulter et modifier la base de données à partir des pages de l'application, tout comme remplir des formulaires, cliquer sur des boutons et naviguer entre les pages d'une application web classique. 38 | 39 | ## Applications ECOLIB et applications de plateforme {#ecolib-applications-and-platform-applications} 40 | 41 | Les applications peuvent être classées en **applications ECOLIB** et **applications de plateforme**. 42 | 43 | > Applications ECOLIB 44 | 45 | Une application ECOLIB met en œuvre certaines fonctions uniques ou des processus métier spécifiques à un ECOLIB, mais elle n'est disponible que dans cet ECOLIB. 46 | 47 | > Applications de plateforme 48 | 49 | Une application de plateforme est applicable à tous les ECOLIBs. Toute application peut être développée en tant qu'application de plateforme. Les développeurs d'IBAX fourniraient des applications de plateforme qui soutiennent les fonctions principales de gouvernance des ECOLIBs, telles que le vote, la notification et la gestion des rôles des membres de l'ECOLIB. 50 | 51 | ## Modèle sous-jacent {#underlying-model} 52 | 53 | > Définition des couches 54 | 55 | IBAX est composé de plusieurs couches : 56 | 57 | * Couche d'interaction utilisateur 58 | 59 | Les membres d'ECOLIB interagissent avec l'application via des pages et des éléments de page. 60 | 61 | * Couche d'application 62 | 63 | Les développeurs d'applications interagissent avec l'état global (tables de données) via des codes de contrat intelligent et des codes de page. 64 | 65 | * Couche d'état global 66 | 67 | Met à jour et synchronise l'état global (base de données) en fonction des opérations écrites dans le grand livre distribué (blockchain). 68 | 69 | * Couche blockchain 70 | 71 | Met à jour le grand livre distribué avec de nouveaux blocs. Les opérations (transactions) enregistrées dans les nouveaux blocs doivent être effectuées sur l'état global. 72 | 73 | * Couche réseau de nœuds 74 | 75 | Implémente le protocole du réseau IBAX, qui distribue, vérifie les transactions et génère de nouveaux blocs sur le réseau de nœuds. De même, les nouveaux blocs sont distribués et vérifiés par le réseau de nœuds. 76 | 77 | Le grand livre distribué de tous les nœuds est maintenu synchronisé. En cas de conflits dans un nœud, le nœud identifiera les blockchains considérées comme valides et les blockchains invalides seront annulées en conséquence. 78 | 79 | * Couche de transaction 80 | 81 | Les transactions sont la base de la génération de blocs et des protocoles blockchain, et les transactions elles-mêmes sont le résultat des opérations effectuées au niveau de l'interaction utilisateur. Les transactions sont générées par Weaver. 82 | 83 | Lorsqu'un utilisateur ou un développeur effectue une opération telle que cliquer sur un bouton sur une page ou implémenter un contrat intelligent à partir de l'éditeur de code, Weaver convertira cette opération en une transaction et l'enverra au nœud réseau auquel il est connecté. 84 | 85 | Par conséquent, le flux des transactions est le suivant: 86 | 87 | * Une opération utilisateur sur une page utilisateur deviendra une transaction; 88 | * La transaction est contenue dans un bloc; 89 | * Le bloc est inclus dans la blockchain; 90 | * Le changement d'opération entraînera un changement d'état global de la blockchain, et cette opération sera appliquée à la base de données; 91 | * Tout changement de base de données sera reflété dans l'application. 92 | 93 | ## Mise en œuvre {#implementation} 94 | 95 | IBAX a deux composants majeurs, à savoir le serveur [go-ibax](https://github.com/IBAX-io/go-ibax) et Weaver [Code source](https://github.com/IBAX-io/weaver). 96 | 97 | Weaver: 98 | * Fournit les pages utilisateur; 99 | * Fournit l'IDE pour le développement d'applications; 100 | * Stocke les clés publiques des comptes utilisateur et effectue l'autorisation; 101 | * Demande les données de la base de données depuis les pages d'application et affiche les pages d'application aux utilisateurs; 102 | * Envoie des transactions au serveur via [API REST](../reference/api2.md); 103 | 104 | Afin de créer automatiquement des transactions en fonction des opérations utilisateur, Weaver convertira ces opérations en transactions lorsque les développeurs d'applications implémenteront un contrat intelligent depuis l'IDE. 105 | 106 | Serveur: 107 | * Conserve l'état global (base de données) du nœud; 108 | * Implémentation du protocole de la blockchain; 109 | * Implémentation des codes de contrat intelligent dans la [Machine Virtuelle](../topics/vm.md) IBAX; 110 | * Implémentation des codes de page dans le [Moteur de Modèles](../topics/templates2.md); 111 | * Implémentation de l'[API RESTful](../reference/api2.md). 112 | 113 | -------------------------------------------------------------------------------- /docs/fr/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # Fichier de configuration du serveur {#server-configuration-file} 2 | 3 | Dans cette section, nous allons introduire les paramètres dans le fichier de configuration du serveur. 4 | 5 | ## Introduction au fichier de configuration du serveur {#introduction-to-the-server-configuration-file} 6 | 7 | Le fichier de configuration du serveur définit la configuration du nœud d'IBAX. 8 | 9 | ## Emplacement {#location} 10 | 11 | Ce fichier se trouve dans le répertoire de travail du serveur et porte le nom `config.toml`. 12 | 13 | ## Sections {#sections} 14 | 15 | Le fichier de configuration comprend les sections suivantes : 16 | 17 | > Section générale 18 | 19 | Il définit le répertoire de travail DataDir, le répertoire du premier bloc FirstBlockPath et d'autres paramètres. 20 | 21 | > [TCPServer] 22 | 23 | Il définit les paramètres du service TCP. 24 | 25 | TCPServer est utilisé pour l'interaction réseau entre les nœuds. 26 | 27 | > [HTTP] 28 | 29 | Il définit les paramètres du service HTTP. 30 | 31 | HTTPServer fournit des API RESTful. 32 | 33 | > [DB] 34 | 35 | Il définit les paramètres de la base de données du nœud PostgreSQL. 36 | 37 | > [StatsD] 38 | 39 | Il définit les paramètres du collecteur d'indicateurs d'opération du nœud StatsD. 40 | 41 | > [Centrifugo] 42 | 43 | Il définit les paramètres du service de notification Centrifugo. 44 | 45 | > [Log] 46 | 47 | Il définit les paramètres du service de journalisation Log. 48 | 49 | > [TokenMovement] 50 | 51 | Il définit les paramètres du service de circulation des jetons TokenMovement. 52 | 53 | ## Un fichier de configuration exemple {#an-example-configuration-file} 54 | 55 | ``` js 56 | PidFilePath = "/ibax-data/go-ibax.pid" 57 | LockFilePath = "/ibax-data/go-ibax.lock" 58 | DataDir = "/ibax-data" 59 | KeysDir = "/ibax-data" 60 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/ibax-temp" 61 | FirstBlockPath = "/ibax-data/1block" 62 | TLS = false 63 | TLSCert = "" 64 | TLSKey = "" 65 | OBSMode = "none" 66 | HTTPServerMaxBodySize = 1048576 67 | MaxPageGenerationTime = 3000 68 | NodesAddr = [] 69 | 70 | [TCPServer] 71 | Host = "127.0.0.1" 72 | Port = 7078 73 | 74 | [HTTP] 75 | Host = "127.0.0.1" 76 | Port = 7079 77 | 78 | [DB] 79 | Name = "ibax" 80 | Host = "127.0.0.1" 81 | Port = 5432 82 | User = "postgres" 83 | Password = "123456" 84 | LockTimeout = 5000 85 | 86 | [StatsD] 87 | Host = "127.0.0.1" 88 | Port = 8125 89 | Name = "ibax" 90 | 91 | [Centrifugo] 92 | Secret = "127.0.0.1" 93 | URL = "127.0.0.1" 94 | 95 | [Log] 96 | LogTo = "stdout" 97 | LogLevel = "ERROR" 98 | LogFormat = "text" 99 | [Log.Syslog] 100 | Facility = "kern" 101 | Tag = "go-ibax" 102 | 103 | [TokenMovement] 104 | Host = "" 105 | Port = 0 106 | Username = "" 107 | Password = "" 108 | To = "" 109 | From = "" 110 | Subject = "" 111 | ``` 112 | -------------------------------------------------------------------------------- /docs/fr/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # Outil de surveillance synchronisée {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor est un outil spécial qui peut être utilisé pour vérifier si la base de données sur le nœud spécifié a été synchronisée. 4 | 5 | L'outil peut être utilisé comme un démon ou peut être lancé pour effectuer une vérification ponctuelle. 6 | 7 | Le principe de fonctionnement de l'outil est basé sur ce qui suit : 8 | 9 | 1. Chaque bloc contient le hachage de toutes les modifications de toutes les transactions, demandez au nœud spécifié de fournir son dernier ID de bloc ; 10 | 2. Ensuite, demandez un bloc avec cet ID à tous les nœuds et comparez les hachages ci-dessus ; 11 | 3. Si les hachages sont différents, un message d'erreur de synchronisation sera envoyé à l'adresse e-mail spécifiée dans la commande. 12 | 13 | ## Emplacement {#location} 14 | 15 | L'outil est situé dans le répertoire `tools/desync_monitor/`. 16 | 17 | ## Drapeaux de la ligne de commande {#command-prompt-flags} 18 | 19 | Les drapeaux suivants peuvent être utilisés depuis l'invite de commande : 20 | 21 | > - **confPath** -- Chemin du fichier de configuration. Le nom de fichier par défaut est `config.toml`; 22 | > - **nodesList** -- Liste des nœuds du bloc demandé, séparés par des virgules. La valeur par défaut est `127.0.0.1:7079`; 23 | > - **daemonMode** -- Démarré en tant que démon et doit être utilisé lorsque l'authentification est requise toutes les N secondes. Ce drapeau est par défaut défini sur `false`; 24 | > - **queryingPeriod** -- Si l'outil est démarré en tant que démon, ce paramètre définit l'intervalle de temps (en secondes) entre les vérifications, `1` seconde par défaut. 25 | 26 | - **alertMessageTo** -- L'adresse e-mail à laquelle les erreurs de synchronisation seront envoyées. 27 | 28 | > - **alertMessageSubj** -- Sujet du message dans le message d'avertissement, le problème de `synchronisation du nœud` par défaut; 29 | > - **alertMessageFrom** -- Adresse à partir de laquelle le message a été envoyé. 30 | > - **smtpHost** -- Hôte du serveur SMTP utilisé pour envoyer des e-mails, `""` par défaut; 31 | > - **smtpPort** -- Port du serveur SMTP utilisé pour envoyer des messages électroniques, `25` par défaut; 32 | > - **smtpUsername** -- Nom d'utilisateur du serveur SMTP, `""` par défaut; 33 | > - **smtpPassword** -- Mot de passe du serveur SMTP, `""` par défaut. 34 | 35 | ## Configuration {#configuration} 36 | 37 | L'outil utilise un fichier de configuration au format toml. 38 | 39 | Par défaut, il recherchera le fichier config.toml dans le dossier où démarrer le fichier binaire. 40 | 41 | Le chemin du fichier peut être modifié avec **configPath**. 42 | 43 | ```text 44 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 45 | 46 | [daemon] 47 | daemon = false 48 | querying_period = 1 49 | 50 | [alert_message] 51 | to = "" 52 | subject = "problem with xxx nodes" 53 | from = "" 54 | 55 | [smtp] 56 | host = "" 57 | port = 25 58 | username = "" 59 | password = "" 60 | ``` 61 | 62 | ### nodes_list {#nodes-list} 63 | 64 | * nodes_list - Liste des nœuds (hôtes) demandant des informations. 65 | 66 | ### [daemon] {#daemon} 67 | 68 | Configuration du mode démon. 69 | 70 | > - **daemon_mode** -- Un outil fonctionne comme un démon et effectue des vérifications de synchronisation. 71 | > - **querying_period** -- Intervalle de temps entre les vérifications de synchronisation. 72 | 73 | ### [alert_message] {#alert-message} 74 | 75 | Paramètres du message d'avertissement. 76 | 77 | > - **to** -- Destinataire des messages d'avertissement d'erreur de synchronisation ; 78 | > - **subject** -- sujet du message; 79 | > - **from** -- e-mail de l'expéditeur. 80 | 81 | ### [smtp] {#smtp} 82 | 83 | Paramètres du serveur de protocole de transfert de courrier simple (SMTP), utilisés pour envoyer des messages d'erreur de synchronisation. 84 | 85 | > - **host** -- Serveur SMTP hébergé; 86 | > - **port** -- Port du serveur SMTP; 87 | > - **username** -- Nom d'utilisateur du serveur SMTP; 88 | > - **password** -- Mot de passe du serveur SMTP; 89 | -------------------------------------------------------------------------------- /docs/it/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: Una rete infrastrutturale cross-chain commerciale decentralizzata 6 | actionText: Avvio veloce → 7 | actionLink: /it/concepts/about-the-platform.html 8 | features: 9 | - title: Una grande riduzione del costo dell'applicazione blockchain 10 | - title: Un ecosistema fisico costruito in modo indipendente 11 | - title: Implementazione rapida di server distribuiti, ambienti di sviluppo e applicazioni 12 | - title: Un DApp Store diversificato e funzionalità BaaS 13 | - title: Risposta effettiva del servizio in pochi secondi 14 | - title: Interazione dati cross-chain e cross-system 15 | - title: Una nuova rete infrastrutturale che integra catene pubbliche, alleanze e rivali 16 | - title: Un meccanismo di consenso personalizzabile 17 | - title: Separazione di front-end e back-end per soddisfare le diverse esigenze di crittografia 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 06/20/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # IBAX Documentazione 24 | 25 | 26 | ## Concetto 27 | 28 | * [IBAX Overview](concepts/about-the-platform.md) 29 | * [The IBAX Network](concepts/blockchain-layers.md) 30 | * [Proof-of-Authority Consensus](concepts/consensus.md) 31 | * [Terms and Definitions](concepts/thesaurus.md) 32 | * [FAQ](concepts/faq.md) 33 | 34 | ## Tutorial 35 | 36 | * [Tutorial for application development](tutorials/app_tutorial.md) 37 | * [Development Tutorial](tutorials/tutorial.md) 38 | 39 | ## Guida 40 | 41 | * [Smart Contracts](topics/script.md) 42 | * [Template Language](topics/templates2.md) 43 | * [Compiler and Virtual Machine](topics/vm.md) 44 | * [Daemon](topics/daemons.md) 45 | 46 | ## Riferimento 47 | 48 | * [RESTful API](reference/api2.md) 49 | * [Platform Parameters](reference/platform-parameters.md) 50 | * [Server Configuration File](reference/backend-config.md) 51 | * [Synchronized Monitoring Tool](reference/desync_monitor.md) 52 | * [JSON-RPC Application Programming Interface](reference/json-rpc.md) 53 | 54 | ## Distribuzione 55 | 56 | * [Deployment of A IBAX Network](howtos/deployment.md) 57 | 58 | -------------------------------------------------------------------------------- /docs/it/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # The IBAX Network {#the-ibax-network} 2 | 3 | 4 | In this section, we will brief you how to use IBAX. 5 | 6 | - [The IBAX Network](#the-ibax-network) 7 | - [Application developers](#application-developers) 8 | - [ECOLIB members](#ecolib-members) 9 | - [ECOLIB applications and platform applications](#ecolib-applications-and-platform-applications) 10 | - [Underlying model](#underlying-model) 11 | - [Implementation](#implementation) 12 | 13 | 14 | If you are interested in the development, use or management of applications in IBAX, then you may not need to understand it at all. 15 | 16 | In IBAX, the blockchain and the blockchain network are hidden from ECOLIB members, administrators, and application developers. IBAX offers [RESTful API](../reference/api2.md) for all user groups, which provide a tamper-proof and distributed access to the **global state** of the blockchain. 17 | 18 | ## Application developers {#application-developers} 19 | 20 | In technical terms, the **global state** is a set of data, which is implemented via IBAX's database. From the perspective of application developers, an application interacts with the database by querying, inserting and updating tables. 21 | 22 | In IBAX, transactions are written into the blockchain by implementing various contracts. These transactions will call contract codes implemented by blockchain network nodes, which will update the global state (database) accordingly. 23 | 24 | For application developers, a contract is a function that data will be written to the database when it is implemented. Pages are like scripts and the page code is a set of page [template](../topics/templates2.md) functions, some of these functions display page elements, while other data comes from the database. Application developers do not need to understand what are transactions, block generation and consensus algorithms, just use it. 25 | 26 | ## ECOLIB members {#ecolib-members} 27 | 28 | Applications written by developers run in an environment called [ECOLIB](thesaurus.md#ecolib). An application usually serves a specific purpose and complete various tasks together with several other applications. 29 | 30 | A user must become a member of an ECOLIB if wants to access applications in it, and it can be a member of multiple different ECOLIBs at the same time. 31 | 32 | ECOLIB members can view and modify the database from application pages, just like filling out forms, clicking buttons and navigating pages in a common web application. 33 | 34 | ## ECOLIB applications and platform applications {#ecolib-applications-and-platform-applications} 35 | 36 | Applications may fall into **ECOLIB applications** and **platform applications**. 37 | 38 | > ECOLIB applications 39 | 40 | An ECOLIB application implements certain unique functions or business processes of an ECOLIB, but it is only available in that ECOLIB. 41 | > Platform applications 42 | 43 | A platform application is applicable to all ECOLIBs. Any application could be developed as a platform application. IBAX developers would provide platform applications that support the core functions for ECOLIB governance, such as voting, notification, and ECOLIB member role management. 44 | 45 | ## Underlying model {#underlying-model} 46 | 47 | > Definition of layers 48 | 49 | IBAX consists of several layers: 50 | 51 | * User interaction layer 52 | 53 | ECOLIB members interact with the application through pages and page elements. 54 | 55 | * Application layer 56 | 57 | Application developers interact with the global state (data tables) through contract codes and page codes. 58 | 59 | * Global state layer 60 | 61 | Update and synchronize the global state (database) based on operations written to the distributed ledger (blockchain) 62 | * Blockchain layer 63 | 64 | Update the distributed ledger with new blocks. Operations (transactions) saved in new blocks must be performed on the global state. 65 | 66 | * Node network layer 67 | 68 | It implemented the IBAX Network protocol, which distributes, verifies transactions and generates new blocks on the node network. Similarly, new blocks are distributed and verified by the node network. 69 | 70 | The distributed ledger of all nodes is kept in sync. If having conflicts in a node, the node will identify which blockchains are considered valid and invalid blockchains will be rolled back accordingly. 71 | 72 | * Transaction layer 73 | 74 | Transactions are the basis for generating blocks and blockchain protocols, and transactions themselves are the results of operations performed at the user interaction layer. Transactions are generated by Weaver. 75 | 76 | When a user or developer performs an operation such as clicking a button on a page or implement a contract from the code editor, Weaver will convert this operation into a transaction and send it to the network node connected to it. 77 | 78 | Therefore, the flow of transactions is as follows: 79 | 80 | * A user operation in a user page will become a transaction; 81 | * The transaction is contained in a block; 82 | 83 | * The block is included in the blockchain; 84 | 85 | * The change of operation will cause the global state of the blockchain to change, and such operation will be applied to the database; 86 | 87 | * Any database change will be reflected in the application. 88 | 89 | ## Implementation {#implementation} 90 | 91 | IBAX has two major components, i.e. server [go-ibax](https://github.com/IBAX-io/go-ibax) and Weaver [Source code](https://github.com/IBAX-io/weaver). 92 | 93 | Weaver: 94 | * Providing the user pages; 95 | * Providing the IDE for application development; 96 | * Storing public keys of user accounts and perform authorization; 97 | * Requesting database data from application pages and display application pages to users; 98 | * Sending transactions to the server through [REST APIs](../reference/api2.md); 99 | 100 | In order to automatically create transactions against user operations, Weaver will convert such operations into transactions when application developers implement a contract from the IDE. 101 | 102 | Server: 103 | * Keeping the global state (database) of the node; 104 | * Implementation of the blockchain protocol; 105 | * Implementation of contract codes in the IBAX [Virtual Machine](../topics/vm.md); 106 | * Implementation of page codes in the [Template Engine](../topics/templates2.md); 107 | * Implementation of [RESTful API](../reference/api2.md). -------------------------------------------------------------------------------- /docs/it/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # Server Configuration File {#server-configuration-file} 2 | 3 | In this section, we will introduce parameters in the server configuration file. 4 | ## Introduction to the server configuration file {#introduction-to-the-server-configuration-file} 5 | 6 | The server configuration file defines the node configuration of IBAX. 7 | ## Location {#location} 8 | 9 | This file is located in the working directory of the server and is named `config.toml`. 10 | ## Sections {#sections} 11 | 12 | The configuration file consists the following sections: 13 | 14 | > general section 15 | 16 | It defines the working directory DataDir, the first block directory FirstBlockPath and other parameters. 17 | 18 | > [TCPServer] 19 | 20 | It defines the TCP service parameters. 21 | 22 | TCPServer is used for the network interaction between nodes. 23 | 24 | > [HTTP] 25 | 26 | It defines the HTTP service parameters. 27 | 28 | HTTPServer provides RESTful APIs. 29 | 30 | > [DB] 31 | 32 | It defines parameters of the PostgreSQL node database. 33 | 34 | > [StatsD] 35 | 36 | It defines parameters of the node operation indicator collector StatsD. 37 | 38 | > [Centrifugo] 39 | 40 | It defines parameters of the notification service Centrifugo. 41 | 42 | > [Log] 43 | 44 | It defines parameters of the log service Log. 45 | 46 | > [TokenMovement] 47 | 48 | It defines parameters of the token circulation service TokenMovement. 49 | 50 | ## An example configuration file {#an-example-configuration-file} 51 | ``` 52 | PidFilePath = "/ibax-data/go-ibax.pid" 53 | LockFilePath = "/ibax-data/go-ibax.lock" 54 | DataDir = "/ibax-data" 55 | KeysDir = "/ibax-data" 56 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/ibax-temp" 57 | FirstBlockPath = "/ibax-data/1block" 58 | TLS = false 59 | TLSCert = "" 60 | TLSKey = "" 61 | OBSMode = "none" 62 | HTTPServerMaxBodySize = 1048576 63 | MaxPageGenerationTime = 3000 64 | NodesAddr = [] 65 | 66 | [TCPServer] 67 | Host = "127.0.0.1" 68 | Port = 7078 69 | 70 | [HTTP] 71 | Host = "127.0.0.1" 72 | Port = 7079 73 | 74 | [DB] 75 | Name = "ibax" 76 | Host = "127.0.0.1" 77 | Port = 5432 78 | User = "postgres" 79 | Password = "123456" 80 | LockTimeout = 5000 81 | 82 | [StatsD] 83 | Host = "127.0.0.1" 84 | Port = 8125 85 | Name = "ibax" 86 | 87 | [Centrifugo] 88 | Secret = "127.0.0.1" 89 | URL = "127.0.0.1" 90 | 91 | [Log] 92 | LogTo = "stdout" 93 | LogLevel = "ERROR" 94 | LogFormat = "text" 95 | [Log.Syslog] 96 | Facility = "kern" 97 | Tag = "go-ibax" 98 | 99 | [TokenMovement] 100 | Host = "" 101 | Port = 0 102 | Username = "" 103 | Password = "" 104 | To = "" 105 | From = "" 106 | Subject = "" 107 | ``` 108 | -------------------------------------------------------------------------------- /docs/it/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # Synchronized Monitoring Tool {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor is a special tool that can be used to verify whether the database on the specified node has been synchronized. 4 | 5 | The tool can be used as a daemon or can be started to perform a one-time check. 6 | 7 | The operating principle of the tool is based on the following: 8 | 9 | 1.Each block contains the hash of all changes of all transactions, request the specified node to provide its last block ID; 10 | 2.Then request a block with this ID from all nodes and compare the above hashes; 11 | 3.If the hashes are different, a synchronization error message will be sent to the email address specified in the command. 12 | 13 | ## Location {#location} 14 | The tool is located in the `tools/desync_monitor/` directory. 15 | 16 | ## Command prompt flags {#command-prompt-flags} 17 | The following flags can be used from the command prompt: 18 | * confPath - Path of the configuration file. The default file name is `config.toml`; 19 | * nodesList - Node list of the requested block, separated by commas. The default is `127.0.0.1:7079`; 20 | * daemonMode - Started as a daemon and should be used when authentication is required every N seconds. This flag is set to `false` by default; 21 | * queryingPeriod - If the tool is started as a daemon, this parameter sets the time interval (in seconds) between checks, `1` second by default. 22 | * alertMessageTo – The email address to which synchronization warning errors will be sent. 23 | * alertMessageSubj - Message subject in the warning message, the `node synchronization` problem by default; 24 | * alertMessageFrom - Address where the message was sent. 25 | * smtpHost - SMTP server host, used to send emails, the `""` by default; 26 | * smtpPort - SMTP server port, used to send email messages, `25` by default; 27 | * smtpUsername - SMTP server username, `""` by default; 28 | * smtpPassword - SMTP server password, `""` by default. 29 | 30 | ## Configuration {#configuration} 31 | The tool uses a configuration file in toml format. 32 | 33 | By default, it will look for the config.toml file in the folder where to start up the binary file. 34 | 35 | The file path can be changed with the configPath flag. 36 | 37 | ``` 38 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 39 | 40 | [daemon] 41 | daemon = false 42 | querying_period = 1 43 | 44 | [alert_message] 45 | to = "" 46 | subject = "problem with xxx nodes" 47 | from = "" 48 | 49 | [smtp] 50 | host = "" 51 | port = 25 52 | username = "" 53 | password = "" 54 | ``` 55 | 56 | ### nodes_list {#nodes-list} 57 | * nodes_list - List of nodes (hosts) requesting information. 58 | 59 | ### [daemon] {#daemon} 60 | Configuration of the daemon mode. 61 | * daemon_mode – A tool works as a daemon and performs synchronization checks. 62 | * querying_period - Time interval between synchronization checks. 63 | 64 | ### [alert_message] {#alert-message} 65 | Warning message parameters. 66 | * to - recipient's e-mail of synchronization error warning messages; 67 | * subject - message subject; 68 | * from - sender's e-mail. 69 | 70 | ### [smtp] {#smtp} 71 | Simple Mail Transfer Protocol (SMTP) server parameters, used to send synchronization error messages. 72 | * host – SMTP server hose; 73 | * port –SMTP server port; 74 | * username – SMTP server user name; 75 | * password –SMTP server password; -------------------------------------------------------------------------------- /docs/ja/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: 分散型商用クロスチェーンインフラストラクチャネットワーク 6 | actionText: クイックスタート → 7 | actionLink: /ja/concepts/about-the-platform.html 8 | features: 9 | - title: ブロックチェーンアプリケーションのコストを大幅に削減 10 | - title: 独立して構築する物理エコシステム 11 | - title: 分散サーバー、開発およびアプリケーション環境の迅速な展開 12 | - title: 多様なDAppストアとBaaS機能 13 | - title: 秒単位の実際のサービス応答 14 | - title: クロスチェーンおよびクロスシステムのデータ相互作用 15 | - title: パブリックチェーン、アライアンスチェーン、およびリバティブチェーンを統合する新しいインフラストラクチャネットワーク 16 | - title: カスタマイズ可能なコンセンサスメカニズム 17 | - title: さまざまな暗号化のニーズを満たすためのフロントエンドとバックエンドの分離 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 06/20/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # IBAX ドキュメンテーション 24 | 25 | 26 | ## コンセプト 27 | 28 | * [IBAX 概要](concepts/about-the-platform.md) 29 | * [IBAX ネットワーク](concepts/blockchain-layers.md) 30 | * [権限証明コンセンサス](concepts/consensus.md) 31 | * [用語と定義](concepts/thesaurus.md) 32 | * [FAQ](concepts/faq.md) 33 | 34 | ## チュートリアル 35 | 36 | * [アプリケーション開発チュートリアル](tutorials/app_tutorial.md) 37 | * [開発チュートリアル](tutorials/tutorial.md) 38 | 39 | ## ガイド 40 | 41 | * [スマートコントラクト](topics/script.md) 42 | * [テンプレート言語](topics/templates2.md) 43 | * [コンパイラと仮想マシン](topics/vm.md) 44 | * [デーモン](topics/daemons.md) 45 | 46 | ## リファレンス 47 | 48 | * [RESTful API](reference/api2.md) 49 | * [プラットフォームパラメータ](reference/platform-parameters.md) 50 | * [サーバー設定ファイル](reference/backend-config.md) 51 | * [同期監視ツール](reference/desync_monitor.md) 52 | * [JSON-RPC アプリケーション プログラミング インターフェイス](reference/json-rpc.md) 53 | 54 | ## 展開 55 | 56 | * [IBAX ネットワークの展開](howtos/deployment.md) 57 | 58 | -------------------------------------------------------------------------------- /docs/ja/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # IBAXネットワーク {#the-ibax-network} 2 | 3 | このセクションでは、IBAXの使用方法について説明します。 4 | 5 | - [IBAXネットワーク](#the-ibax-network) 6 | - [アプリケーション開発者](#application-developers) 7 | - [ECOLIBメンバー](#ecolib-members) 8 | - [ECOLIBアプリケーションとプラットフォーム・アプリケーション](#ecolib-applications-and-platform-applications) 9 | - [基礎となるモデル](#underlying-model) 10 | - [実装](#implementation) 11 | 12 | 13 | 14 | 15 | 16 | 17 | IBAXにおけるアプリケーションの開発、利用、管理に興味があるのであれば、全く理解する必要はないかもしれません。 18 | 19 | IBAXでは、ブロックチェーンとブロックチェーン・ネットワークは、ECOLIBメンバー、管理者、アプリケーション開発者からは隠されています。IBAXでは、すべてのユーザーグループに対して[RESTful API](../reference/api2.md) を提供しており、ブロックチェーンの **global state** への改ざん防止と分散アクセスを提供します。 20 | 21 | ## アプリケーション開発者 {#application-developers} 22 | 23 | 技術用語では、**グローバルステート**はデータのセットであり、IBAXのデータベースを介して実装されています。アプリケーション開発者の視点から見ると、アプリケーションはテーブルの問い合わせ、挿入、更新によってデータベースと相互作用する。 24 | 25 | IBAXでは、さまざまなコントラクトを実装することで、ブロックチェーンにトランザクションが書き込まれます。これらのトランザクションは、ブロックチェーンネットワークノードが実装するコントラクトコードを呼び出し、それに応じてグローバルステート（データベース）を更新する。 26 | 27 | アプリケーション開発者にとっては、コントラクトが実装されるとデータベースにデータが書き込まれる機能である。ページはスクリプトのようなもので、ページコードはページ[テンプレート](../topics/templates2.md)関数のセットであり、これらの関数の一部はページ要素を表示し、他のデータはデータベースからもたらされます。アプリケーション開発者は、トランザクション、ブロック生成、コンセンサス・アルゴリズムが何であるかを理解する必要はなく、ただそれを使うだけでよい。 28 | 29 | ## ECOLIBメンバー {#ecolib-members} 30 | 31 | 開発者が書いたアプリケーションは、[ECOLIB](thesaurus.md#ecolib)と呼ばれる環境下で動作します。アプリケーションは通常、特定の目的を持ち、他のいくつかのアプリケーションと一緒に様々なタスクをこなします。 32 | 33 | ECOLIB内のアプリケーションにアクセスするには、ECOLIBのメンバーになる必要があり、同時に複数の異なるECOLIBのメンバーになることができる。 34 | 35 | ECOLIBのメンバーは、一般的なWebアプリケーションでフォームに記入したり、ボタンをクリックしたり、ページをナビゲートするように、アプリケーションのページからデータベースを見たり、変更したりすることができます。 36 | 37 | ## ECOLIBアプリケーションとプラットフォーム・アプリケーション {#ecolib-applications-and-platform-applications} 38 | 39 | アプリケーションは、**ECOLIBアプリケーション**と**プラットフォーム・アプリケーション**に分類されます。 40 | 41 | ECOLIBアプリケーション 42 | 43 | ECOLIBアプリケーションは、あるECOLIB独自の機能やビジネスプロセスを実装したもので、そのECOLIBでしか利用できない。 44 | プラットフォームアプリケーション 45 | 46 | プラットフォームアプリケーションは、すべてのECOLIBに適用可能です。どんなアプリケーションでもプラットフォーム・アプリケーションとして開発することができる。IBAXの開発者は、投票、通知、ECOLIBメンバーの役割管理など、ECOLIBガバナンスの中核機能をサポートするプラットフォーム・アプリケーションを提供する。 47 | 48 | ## 基礎となるモデル {#underlying-model} 49 | 50 | レイヤーの定義 51 | 52 | IBAXはいくつかのレイヤーから構成されています： 53 | 54 | * ユーザーインタラクションレイヤー 55 | 56 | ECOLIBメンバーは、ページとページ要素を通じてアプリケーションと対話する。 57 | 58 | * アプリケーション層 59 | 60 | アプリケーション開発者は、契約コードとページコードを通じてグローバルな状態（データテーブル）と対話する。 61 | 62 | * グローバルステート層 63 | 64 | 分散台帳（ブロックチェーン）に書き込まれた操作に基づき、グローバルステート（データベース）の更新・同期を行う。 65 | * ブロックチェーンレイヤー 66 | 67 | 分散台帳を新しいブロックに更新する。新しいブロックに保存された操作（トランザクション）は、グローバル状態に対して実行する必要があります。 68 | 69 | * ノード・ネットワーク層 70 | 71 | IBAX Networkプロトコルを実装し、ノードネットワーク上でトランザクションの分散、検証、新しいブロックの生成を行う。同様に、新しいブロックもノードネットワークで配布され、検証される。 72 | 73 | すべてのノードの分散型台帳は同期された状態に保たれます。ノードで競合が発生した場合、ノードはどのブロックチェーンが有効とみなされるかを識別し、無効なブロックチェーンはそれに応じてロールバックされます。 74 | 75 | * トランザクション層 76 | 77 | トランザクションはブロックとブロックチェーンプロトコルを生成するための基礎であり、トランザクション自体はユーザーインタラクション層で行われた操作の結果である。トランザクションはWeaverによって生成されます。 78 | 79 | ユーザーや開発者がページ上のボタンをクリックしたり、コードエディターからコントラクトを実装したりといった操作を行うと、Weaverはこの操作をトランザクションに変換して、接続しているネットワークノードに送信する。 80 | 81 | したがって、トランザクションの流れは次のようになります： 82 | 83 | * ユーザーページでのユーザー操作がトランザクションとなる； 84 | * トランザクションはブロックに含まれる； 85 | * そのブロックはブロックチェーンに含まれる； 86 | * 操作の変更によりブロックチェーンのグローバルな状態が変化し、その操作はデータベースにも適用される； 87 | * データベースの変更は、アプリケーションに反映されます。 88 | 89 | ## 実装 {#implementation} 90 | 91 | IBAXは、サーバ[go-ibax](https://github.com/IBAX-io/go-ibax)とWeaver[ソースコード](https://github.com/IBAX-io/weaver)という2つの大きなコンポーネントを持っています。 92 | 93 | Weaverは、以下のようなものです： 94 | * ユーザーページを提供する； 95 | * アプリケーション開発のためのIDEを提供する； 96 | * ユーザーアカウントの公開鍵を保存し、認可を行う； 97 | * アプリケーションページからデータベースデータを要求し、ユーザーにアプリケーションページを表示する； 98 | * [REST API](../reference/api2.md) を通してサーバーにトランザクションを送信する； 99 | 100 | ユーザーの操作に対して自動的にトランザクションを作成するため、アプリケーション開発者がIDEからコントラクトを実装する際に、Weaverがその操作をトランザクションに変換します。 101 | 102 | サーバーです： 103 | * ノードのグローバルな状態（データベース）を保持する； 104 | * ブロックチェーンプロトコルの実装 105 | * IBAX[仮想マシン](../topics/vm.md)におけるコントラクトコードの実装； 106 | * [ テンプレートエンジン ]（.../topics/templates2.md ）にページコードを実装する； 107 | * [RESTful API](・・・/reference/api2.md)を実装しています。 108 | -------------------------------------------------------------------------------- /docs/ja/concepts/consensus.md: -------------------------------------------------------------------------------- 1 | 2 | # 分散型プルーフオブオーソリティ・コンセンサス {#decentralized-proof-of-authority-consensus} 3 | 4 | * 分散型権威証明コンセンサスとは？ 5 | 6 | * DPoAコンセンサスの利点 7 | 8 | * DPoA コンセンサスと一般的な攻撃手段 9 | 10 | * IBAX における DPoA コンセンサスの実装 11 | 12 | このセクションでは、分散型認証コンセンサス（Decentralized Proof-of-Authority consensus）とそのIBAXでの実装について説明します。 13 | 14 | 15 | - [分散型権威証明コンセンサスとは](#what-is-decentralized-proof-of-authority-consensus) 16 | - [DPoAコンセンサスの利点](#advantages-of-dpoa-consensus) 17 | - [DPoAのコンセンサスと共通の攻撃手段](#dpoa-consensus-and-common-means-of-attack) 18 | - [DoS](#dos) 19 | - [51%攻撃](#percent-attack-51) 20 | - [IBAXにおけるDPoAコンセンサスの実装](#implementation-of-dpoa-consensus-in-ibax) 21 | - [名誉ノード](#honor-node) 22 | - [リーダーノード](#leader-node) 23 | - [新しいブロックの生成](#generation-of-new-blocks) 24 | - [フォークス](#forks) 25 | 26 | ## 分散型権威証明コンセンサスとは？{#what-is-decentralized-proof-of-authority-consensus} 27 | 28 | IBAX Networkは、商用アプリケーションのシナリオや実環境を考慮し、新しいコンセンサスメカニズムであるDPoA（Decentralized Proof of Authority）を構築しました。 29 | 30 | 分散化は、常に私たちの確固たる信念です。それは、IBAXのインフラ・ネットワーク環境だけを指すのではありません。IBAXネットワークで作られたそれぞれのecoLibに分散を根付かせ、それぞれのecoLibで高度な自己統治を実現するための技術的な解決策を講じていくのです。高度に分散した自治を実現するために、全体のアーキテクチャや技術的な実装に多くの変更を加えています。しかし、実際には、中央集権的な管理概念を避けることはできません。中央集権と分散化のバランスをとるために、DPoAコンセンサスメカニズムに加えて、一定の報酬とインセンティブプログラムを策定しました。 31 | 32 | IBAX Networkは、分散、弱い中央集権、認証局を組み合わせた新しい合意メカニズムを構築しました。それをDPoA（Decentralized Proof of Authority）と呼んでいます。IBAX Network全体の継続性を確保するため、コンセンサスはIBAX Public Networkだけでなく、各ユーザーやユーザーグループが作成したecoLibsも対象とします。これにより、真に自治され、分散化され、公正で透明性が高く、不正のない分散型自律組織（DAO）を実現します。 33 | 34 | DPoAには、ネットワーク攻撃に対する予防メカニズムがあり、ネットワークを守り、新しいIBXCコインを鋳造するMint Nodeの作成が可能です。IBAXCoinの保有者は、IBXCの流動性残高の一部をミントノードにステークして、ミント＆ステーク排出リワードを得ることができます。ミントとステークは、攻撃のコストと難易度を高め、IBXCコインの総価値を比例して増加させる役割を果たします。このメカニズムにより、あらゆる攻撃の確率と被害は限りなくゼロに近くなります。 35 | 36 | 37 | ## DPoAコンセンサスの利点 {#advantages-of-dpoa-consensus} 38 | 39 | DPoAコンセンサスは、PoW（Proof-of-Work）やPoS（Proof-of-Stake）コンセンサスと比較して、以下のような利点がある： 40 | 41 | * 高性能なハードウェアを必要としない。PoWコンセンサスと比較して、DPoAコンセンサスを実装するノードは、複雑な数学的論理タスクを解くために計算資源を費やす必要がありません； 42 | 43 | * 新しいブロックを生成する間隔は予測可能だが、PoWコンセンサスとPoSコンセンサスでは異なる； 44 | 45 | * 高いトランザクションレート。認可されたネットワークノードが指定された時間間隔でブロックを生成するため、取引検証の速度が向上する。 46 | 47 | * 51%のノードが危険でない限り、危険なノードや悪意のあるノードに対する耐性がある。IBAXは、ノードを禁止し、ブロック生成権を剥奪するメカニズムを実装しています。 48 | 49 | ## DPoAのコンセンサスと共通の攻撃手段 {#dpoa-consensus-and-common-means-of-attack} 50 | 51 | ### DoS {#dos} 52 | 53 | 攻撃者は、ネットワーク上の標的となるノードに大量のトランザクションやブロックを送信し、その動作を妨害してサービスを利用できなくすることを試みることがある。 54 | 55 | DPoA機構はDoS攻撃から防御することが可能である： 56 | 57 | * ネットワークノードは事前に認証されるため、DoS攻撃に耐えられるノードにのみブロック生成権を付与することができる。 58 | 59 | * ネットワークノードは事前認証されるため，DoS攻撃に耐えられるノードにのみブロック生成権を付与することができる． 60 | 61 | ### 51%攻撃 {#percent-attack-51} 62 | 63 | DPoAコンセンサスのシナリオでは、51%攻撃は攻撃者が51%のネットワークノードを制御する必要があります。しかし、PoWコンセンサスのシナリオは異なり、攻撃者はネットワークの51％の計算能力を得る必要がある。許可されたブロックチェーン・ネットワークでノードの制御を得ることは、計算能力を得ることよりもはるかに困難である。 64 | 65 | 例えば、PoWコンセンサスを実装したネットワークでは、攻撃者は制御されるネットワークセグメントの計算能力（性能）を高めることができ、制御されるノードの割合を増やすことができます。DPoAコンセンサスでは、ノードの計算能力はブロックチェーン・ネットワークの決定に影響を与えないため、このようなことは意味がない。 66 | 67 | ## IBAXにおけるDPoAコンセンサスの実装 {#implementation-of-dpoa-consensus-in-ibax} 68 | 69 | ### 名誉ノード {#honor-node} 70 | 71 | IBAXでは、新しいブロックを生成するのは名誉ノードのみであり、彼らがブロックチェーンネットワークと分散台帳を維持しています。 72 | 73 | 名誉ノードのリストはブロックチェーンのレジストリに保持されています。ノードの順序は、ノードが新しいブロックを生成する順序を決定します。 74 | 75 | ### リーダーノード {#leader-node} 76 | 77 | 以下の式により、現在の**リーダーノード**、すなわち現在の時刻に新しいブロックを生成する必要があるノードが決定されます。 78 | 79 | ``` 80 | leader = ((time - first) / step) % nodes 81 | ``` 82 | 83 | > リーダー 84 | 85 | 現在のリーダーノード。 86 | 87 | > 時間 88 | 89 | 現在の時刻（UNIX）。 90 | 91 | > 最初 92 | 93 | 最初のブロック生成時刻（UNIX）。 94 | 95 | > ステップ 96 | 97 | ブロック生成間隔の秒数。 98 | 99 | > ノード 100 | 101 | 総リーダーノード数。 102 | 103 | 104 | ### 新しいブロックの生成 {#generation-of-new-blocks} 105 | 106 | 新しいブロックは、現在の時間間隔の[リーダーノード](#leader-node)によって生成されます。各時間間隔で、リーダーの役割はリーダーノードリストから次のリーダーノードに渡されます。 107 | 108 | ![avatar](/block-generation.png) 109 | 110 | a) 新しいブロックの生成手順 111 | 112 | 新しいブロックを生成するための主な手順は次のとおりです： 113 | 114 | 1. ノードのトランザクションキューからすべての新しいトランザクションを収集します。 115 | 116 | 2. トランザクションを1つずつ実行します。無効または実行不可能なトランザクションは拒否されます。 117 | 118 | 3. [ブロック生成制限](../reference/platform-parameters.md#configure-the-generation-of-blocks)を満たしているかどうかを確認します。 119 | 120 | 4. 有効なトランザクションを含むブロックを生成し、ECDSAアルゴリズムを使用してリーダーノードの秘密鍵で署名します。 121 | 122 | 5. このブロックを他のリーダーノードに送信します。 123 | 124 | b) 新しいブロックの検証 125 | 126 | 他のリーダーノードで新しいブロックを検証する手順： 127 | 128 | 1. 新しいブロックを受信して検証します： 129 | 130 | – 新しいブロックが現在の時間間隔のリーダーノードによって生成されたものかどうかを確認します。 131 | 132 | – 他のブロックが現在の時間間隔のリーダーノードによって生成されたものがないかどうかを確認します。 133 | 134 | – 新しいブロックが正しく署名されているかどうかを確認します。 135 | 136 | 2. ブロックからトランザクションを1つずつ実行します。トランザクションが正常に実行され、[ブロック生成制限](../reference/platform-parameters.md#configure-the-generation-of-blocks)の範囲内であるかどうかを確認します。 137 | 138 | 3. 前のステップに基づいて、ブロックを追加または拒否します： 139 | 140 | – ブロックの検証が成功した場合、新しいブロックを現在のノードのブロックチェーンに追加します。 141 | 142 | – ブロックの検証に失敗した場合、ブロックを拒否して「不正なブロック」トランザクションを送信します。 143 | 144 | – この無効なブロックを生成したリーダーノードが引き続き不正なブロ 145 | 146 | 147 | ### フォークス {#forks} 148 | 149 | **フォーク**は、ブロックチェーンの残りとは独立して生成された1つ以上のブロックを含む、ブロックチェーンの代替バージョンです。 150 | 151 | フォークは通常、ネットワークの一部が同期解除されたときに発生します。フォークの原因となる可能性のある要素は、高いネットワークの遅延、意図的または意図しない時間制限の違反、ノード間の時刻の非同期です。ネットワークノードが著しい地理的分布を持つ場合、ブロック生成間隔を増やす必要があります。 152 | 153 | フォークは、最も長いブロックチェーンのルールに従って解決されます。2つのブロックチェーンバージョンが検出された場合、リーダーノードは短いバージョンをロールバックし、長いバージョンを受け入れます。 154 | 155 | ![avatar](/block-fork-resolution.png) 156 | -------------------------------------------------------------------------------- /docs/ja/concepts/faq.md: -------------------------------------------------------------------------------- 1 | 2 | # よくある質問 {#faq} 3 | 4 | - [ 1.IBAXについて簡単に教えてください](#question-1) 5 | - [ 2.IBAXはビットコイン、イーサリアム、その他のブロックチェーンに適用できますか](#question-2) 6 | - [3. IBAXと、スマートコントラクトを実行するためのメカニズムが組み込まれた他のパブリックブロックチェーンプラットフォームとの主な違いは何ですか](#question-3) 7 | - [4.独自の暗号通貨を持っていますか](#question-4) 8 | - [5.オナーノードとは何か、誰が維持できるのか](#question-5) 9 | - [6.プラットフォームのエコシステムとは何ですか](#question-6) 10 | - [7.誰がエコシステムを作ることができるのか](#question-7) 11 | - [8. ユーザーはどのようにしてエコシステムのメンバーになるのですか](#question-8) 12 | - [9. 1人のユーザーが複数のエコシステムを作ることはできますか](#question-9) 13 | - [10. プラットフォームアプリケーションとは何ですか](#question-10) 14 | - [11. アプリケーションの作成にはどのようなプログラミング言語が使われますか](#question-11) 15 | - [12. アプリケーションを作成し、ユーザーと対話するために使用されるソフトウェアは何ですか](#question-12) 16 | - [13. プラットフォーム契約は、サードパーティーのAPIを使用してデータにアクセスできますか](#question-13) 17 | - [14. ブロックチェーンに保存されている契約は変更できますか](#question-14) 18 | - [15. スマートローとは何ですか](#question-15) 19 | - [16. 契約は他の契約を呼び出して実行することができますか](#question-16) 20 | - [17. アプリケーションはマスター契約で実行されますか](#question-17) 21 | - [18. アプリケーションを異なる言語にローカライズすることはできますか](#question-18) 22 | - [19. テンプレート言語を使用せずにページを作成できますか](#question-19) 23 | - [20. ページはブロックチェーンに保存されるのでしょうか](#question-20) 24 | - [21. 契約業務に使用できるデータベースはどのようなものがありますか](#question-21) 25 | - [22. データベースのテーブルのデータへのアクセスをどのように管理するか](#question-22) 26 | - [23. エコシステム内のアプリケーションは、別のエコシステムの他のアプリケーションとデータを交換できますか](#question-23) 27 | - [24. 新しいエコシステム内のアプリケーションはすべてゼロから書かなければならないのでしょうか](#question-24) 28 | - [25.アプリケーションの運用に料金はかかりますか](#question-25) 29 | - [26. アプリケーションの運用費用は誰が負担するのですか](#question-26) 30 | - [27. エコシステム内のアプリケーションを脆弱性による攻撃から守る方法はありますか](#question-27) 31 | - [28. 将来の計画ではどのような新機能が実装されるのでしょうか](#question-28) 32 | - [29. 操作性をどのように証明するのか](#question-29) 33 | 34 | ## 1. IBAXについて簡単に説明してください。 {#question-1} 35 | 36 | * IBAXは、統合アプリケーション開発環境をベースにしたデジタルエコシステムを構築するブロックチェーンプラットフォームです。マルチレベルの許可システムを持ち、データ、インターフェース、スマートコントラクトのアクセス権を管理します。 37 | 38 | ## 2. IBAXはBitcoin、Ethereumまたは他のブロックチェーンに適用できますか？ {#question-2} 39 | 40 | * 適用できません。IBAXは独自のオリジナルブロックチェーンをベースにしています。 41 | 42 | ## 3. IBAXと他の内部にスマートコントラクトの実行メカニズムを備えた公開ブロックチェーンプラットフォームとの主な違いは何ですか？ {#question-3} 43 | 44 | * IBAXには、上記のブロックチェーンで見つけることができない独自の機能があります： 45 | * シングルクライアントソフトウェア内の統合アプリケーション開発環境があります； 46 | * ページデザイン用の特別なテンプレート言語Logicorとコントラクト言語Needleが連携しています； 47 | * メンバー、役割、コントラクトに権限を付与できる、データ、インターフェース、スマートコントラクトのアクセス権を管理するマルチレベルの許可システムがあります； 48 | * ブロックチェーンアプリケーションを作成し、ユーザーがそれらとやり取りするための自律ソフトウェア環境として使用されるエコシステムがあります； 49 | * スマートローズ（専用のスマートコントラクト）で書かれた一連のルールである法的システムがあり、プラットフォームユーザーとの関係を規制し、問題解決のためのプロトコルパラメータの変更プロセスを定義します。 50 | 51 | ## 4. 独自の暗号通貨はありますか？ {#question-4} 52 | 53 | * はい、IBAXは独自のトークンであるIBXCを使用しています。 54 | 55 | ## 5. ノードとは何ですか？誰がメンテナンスを行いますか？ {#question-5} 56 | 57 | * ノードは、トランザクションの検証と新しいブロックの生成権限を持つネットワークノードです。 58 | * 十分な処理能力と耐障害性を持つネットワークノードは、ノードになることができます。IBAXはProof of Authority（PoA）のコンセンサスメカニズムを使用しています。エコシステムの投票に基づいて検証ノードになることができますが、プラットフォームのトークン所有者が正常な運用能力を持つことが証明されたエコシステムのみがそのような投票に参加できます。この権限のアルゴリズムを使用して、マスターノードはネットワークの運用を維持することが最も望ましいため、主要なエコシステムによって実行されます。 59 | 60 | ## 6. プラットフォームエコシステムとは何ですか？ {#question-6} 61 | 62 | * エコシステムは、実際にはブロックチェーンアプリケーションを作成し、ユーザーの操作を行うための自律ソフトウェア環境です。 63 | 64 | ## 7. 誰がエコシステムを作成できますか？ {#question-7} 65 | 66 | * プラットフォームのすべてのユーザーが新しいエコシステムを作成できます。 67 | 68 | ## 8. ユーザーはどのようにエコシステムのメンバーになりますか？ {#question-8} 69 | 70 | * ユーザーは既存のいずれかのエコシステムのメンバーとして登録することができます。エコシステムの戦略は、新しいエコシステムのキーパブリック情報を専用のエコシステムカタログに公開する異なるメンバーの入会手続きを定義します。 71 | 72 | ## 9. 1人のユーザーが複数のエコシステムを作成できますか？ {#question-9} 73 | 74 | * はい、各ユーザーは任意の数のエコシステムを作成することができ、複数のエコシステムのメンバーにもなることができます。 75 | 76 | ## 10. プラットフォームアプリケーションとは何ですか？ {#question-10} 77 | 78 | * アプリケーションは、機能やサービスを実装した完全なソフトウェア製品です。アプリケーションにはデータベーステーブル、コントラクト、およびページが含まれます。 79 | 80 | ## 11. アプリケーションを作成するために使用するプログラミング言語は何ですか？ {#question-11} 81 | 82 | * コントラクトは、プラットフォームチームによって開発されたNeedle言語で書かれます。詳細については、[スマートコントラクト](../topics/script.md)を参照してください。 83 | 84 | * ページはLogicor言語で書かれており、ページテンプレート言語です。詳細については、[テンプレート言語](../topics/templates2.md)を参照してください。 85 | 86 | ## 12. アプリケーションを作成し、ユーザーとやり取りするために使用するソフトウェアは何ですか？ {#question-12} 87 | 88 | * アプリケーションプログラムはWeaverで書かれ、実行されます。他のソフトウェアは必要ありません。 89 | 90 | ## 13. プラットフォームのコントラクトはサードパーティのAPIを使用してデータにアクセスできますか？ {#question-13} 91 | 92 | * いいえ、コントラクトはブロックチェーンに直接保存されたデータにのみアクセスできます。外部データソースの処理には[CLB](about-the-platform.md#virtual-private-ecosystem)が使用されます。 93 | 94 | ## 14. ブロックチェーンに保存されたコントラクトは変更できますか？ {#question-14} 95 | 96 | * はい、コントラクトは変更できます。コントラクトの変更権限は作成者によって指定され、変更を拒否する権限や、コントラクトやメンバーによる変更の許可、またはスマートローに複雑な条件のセットを構成する権限を付与することができます。 97 | * Weaverはすべてのバージョンのコントラクトにアクセスできるようにします。 98 | 99 | 100 | ## 15. スマートローとは何ですか？ {#question-15} 101 | 102 | * スマートローは、従来の契約の操作を制御し制限するために設計された契約です。これにより、エコシステムメンバーの活動を制御し制限することができます。 103 | * スマートローのセットは、エコシステムの法的システムと見なすことができます。 104 | 105 | ## 16. コントラクトは他のコントラクトを呼び出して実行できますか？ {#question-16} 106 | 107 | * はい、コントラクトは直接アドレッシングによって他のコントラクトを呼び出し、パラメータを提供するか、リンク名でコントラクトを呼び出すことができます。詳細については、[スマートコントラクト](../topics/script.md)を参照してください。 108 | 109 | ## 17. アプリケーションはマスターコントラクトで実行されますか？ {#question-17} 110 | 111 | * いいえ、コントラクトは特定の機能を実行する自律型のプログラムモジュールです。各コントラクトは指定されたデータを受け取り、それらのデータの正当性を確認し、データベースにトランザクションとして記録されるいくつかの操作を実行するように構成されます。 112 | 113 | ## 18. アプリケーションを異なる言語にローカライズできますか？ {#question-18} 114 | 115 | * はい、Weaverには組み込みのローカライゼーションサポートメカニズムがあり、任意の言語でページを作成することができます。 116 | 117 | ## 19. テンプレート言語を使用せずにページを作成できますか？ {#question-19} 118 | 119 | * はい、プラットフォームの[RESTful API](../reference/api2.md) v2を使用して実行できます。 120 | 121 | ## 20. ページはブロックチェーンに保存されますか？ {#question-20} 122 | 123 | * はい、ページとコントラクトはブロックチェーンに保存されます。これにより、改ざんされることが防止されます。 124 | 125 | ## 21. コントラクト操作にはどのような種類のデータベースを使用できますか？ {#question-21} 126 | 127 | * 現在は、PostgreSQLが使用されています。 128 | 129 | ## 22. データベーステーブル内のデータへのアクセスはどのように管理されますか？ {#question-22} 130 | 131 | * エコシステムメンバー、役割、または指定されたコントラクトの構成に対して、新しいフィールド、新しいエントリ、またはデータの列のアクセス許可を追加または変更することができます。特定の操作を実行して作成されたコントラクトは除外されます。 132 | 133 | ## 23. エコシステム内のアプリケーションは、他のエコシステムのアプリケーションとデータを交換できますか？ {#question-23} 134 | 135 | * はい、データの交換は、すべてのエコシステムに適用されるグローバルデータテーブルを介して組織することができます。 136 | 137 | ## 24. 新しいエコシステム内のすべてのアプリケーションをゼロから作成する必要がありますか？ {#question-24} 138 | 139 | * いいえ、新しいエコシステムにはいくつかのデフォルトのアプリケーションがあります： 140 | * エコシステムメンバーと役割を管理する機構 141 | * 他のトークンの発行と設定 142 | * 投票システム 143 | * 通知システム 144 | * エコシステムメンバー間のメッセンジャー 145 | 146 | これらのアプリケーションは、特定のエコシステムの特別なニーズに合わせて編集および設定することができます。 147 | 148 | ## 25. アプリケーションの操作には料金が発生しますか？ {#question-25} 149 | 150 | * はい、アプリケーションのリソース利用にはプラットフォームでの料金が必要です。 151 | 152 | ## 26. アプリケーションの運用費用は誰が支払いますか？ {#question-26} 153 | 154 | 対応するアカウントアドレスについて、アプリケーションの運用費用を支払う方法は現在4つあります： 155 | * コントラクト呼び出し元の場合、ユーザーがコントラクトを呼び出すと、デフォルトでユーザーのアカウントから手数料が支払われます。 156 | * コントラクトのバインディング当事者の場合、手数料はコントラクト作成者が指定したバインディングアカウントから支払われます。 157 | * エコシステム作成者の場合、エコシステム内のすべてのアプリケーションの手数料は、それぞれのエコシステム作成者によって支払われます。 158 | 159 | * 専用エコシステムウォレット。各エコシステムには専用のアカウントがあります。エコシステム作成者がそれをアクティブ化した場合、エコシステム内のすべてのアプリケーションの手数料はこのアカウントから支払われます。 160 | 161 | 支払いの優先順位：専用エコシステムウォレット>エコシステム作成者>コントラクトバインディング当事者>コントラクト呼び出し元。 162 | 163 | ## 27. エコシステム内のアプリケーションを脆弱性による攻撃からどのように保護しますか？ {#question-27} 164 | 165 | * プラットフォームチームもアプリケーションコードのエラーを完全に回避する方法はないことを認識しています。特に、アプリケーションは任意のユーザーによって作成される可能性があるためです。そのため、脆弱性の悪用による影響を排除するメカニズムを確立することにしました。法的システムは、攻撃操作を停止し、いくつかのトランザクションを使用してアプリケーションを元の状態に復元することができます。法的システムは、そのようなコントラクトを実行する権限と、これらの権限を付与するための投票手続きを定めています。 166 | 167 | ## 28. 将来の計画ではどのような新機能が実装される予定ですか？ {#question-28} 168 | 169 | * ビジュアルスマートコントラクトデザイナー 170 | * ハイブリッドデータベース（SQLおよびNoSQL）のサポート 171 | * 異なるエコシステムからのトランザクションの並行マルチスレッド処理 172 | * クライアント上でのリソース集約的な計算の実行 173 | * エコシステムのホスティングおよび計算能力の交換 174 | * 子ノード。サーバー上で一部のブロックのみを保存 175 | * セマンティックリファレンス（オントロジー）を使用して、プラットフォーム内のデータ操作を統一する 176 | 177 | ## 29. IBAXの機能を証明する方法はありますか？ {#question-29} 178 | 179 | * IBAX Network上で、概念実証プロジェクトや事例がいくつか実装されています。これには、社会化された税金徴収と電子請求書の生成と流通システム、医療機器監視、偽造防止とトレーシングシステム、金融と監視システム、投票/投票システム、ビジネス登録、貿易ファイナンスツール、資産登録契約管理システムなどがあります。 180 | -------------------------------------------------------------------------------- /docs/ja/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # サーバー設定ファイル {#server-configuration-file} 2 | 3 | このセクションでは、サーバー設定ファイルのパラメータについて説明します。 4 | ## サーバー設定ファイルの概要 {#introduction-to-the-server-configuration-file} 5 | 6 | サーバー設定ファイルは、IBAXのノード設定を定義します。 7 | ## 位置 {#location} 8 | 9 | このファイルは、サーバーの作業ディレクトリにあり、`config.toml`という名前で保存されています。 10 | ## セクション {#sections} 11 | 12 | 設定ファイルには、次のセクションが含まれています： 13 | 14 | > generalセクション 15 | 16 | 作業ディレクトリDataDir、最初のブロックディレクトリFirstBlockPathなどのパラメータを定義します。 17 | 18 | > [TCPServer] 19 | 20 | TCPサービスのパラメータを定義します。 21 | 22 | TCPServerは、ノード間のネットワークのやり取りに使用されます。 23 | 24 | > [HTTP] 25 | 26 | HTTPサービスのパラメータを定義します。 27 | 28 | HTTPServerは、RESTful APIを提供します。 29 | 30 | > [DB] 31 | 32 | PostgreSQLノードデータベースのパラメータを定義します。 33 | 34 | > [StatsD] 35 | 36 | ノードの操作指標収集ツールStatsDのパラメータを定義します。 37 | 38 | > [Centrifugo] 39 | 40 | 通知サービスCentrifugoのパラメータを定義します。 41 | 42 | > [Log] 43 | 44 | ログサービスLogのパラメータを定義します。 45 | 46 | > [TokenMovement] 47 | 48 | トークンの流通サービスTokenMovementのパラメータを定義します。 49 | 50 | ## サンプル設定ファイル {#an-example-configuration-file} 51 | 52 | ``` 53 | PidFilePath = "/IBAX-data/go-ibax.pid" 54 | LockFilePath = "/IBAX-data/go-ibax.lock" 55 | DataDir = "/IBAX-data" 56 | KeysDir = "/IBAX-data" 57 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/IBAX-temp" 58 | FirstBlockPath = "/IBAX-data/1block" 59 | TLS = false 60 | TLSCert = "" 61 | TLSKey = "" 62 | OBSMode = "none" 63 | HTTPServerMaxBodySize = 1048576 64 | MaxPageGenerationTime = 3000 65 | NodesAddr = [] 66 | 67 | [TCPServer] 68 | Host = "127.0.0.1" 69 | Port = 7078 70 | 71 | [HTTP] 72 | Host = "127.0.0.1" 73 | Port = 7079 74 | 75 | [DB] 76 | Name = "IBAX" 77 | Host = "127.0.0.1" 78 | Port = 5432 79 | User = "postgres" 80 | Password = "123456" 81 | LockTimeout = 5000 82 | 83 | [StatsD] 84 | Host = "127.0.0.1" 85 | Port = 8125 86 | Name = "IBAX" 87 | 88 | [Centrifugo] 89 | Secret = "127.0.0.1" 90 | URL = "127.0.0.1" 91 | 92 | [Log] 93 | LogTo = "stdout" 94 | LogLevel = "ERROR" 95 | LogFormat = "text" 96 | [Log.Syslog] 97 | Facility = "kern" 98 | Tag = "go-ibax" 99 | 100 | [TokenMovement] 101 | Host = "" 102 | Port = 0 103 | Username = "" 104 | Password = "" 105 | To = "" 106 | From = "" 107 | Subject = "" 108 | ``` 109 | -------------------------------------------------------------------------------- /docs/ja/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # 同期モニタリングツール {#synchronized-monitoring-tool} 2 | 3 | Desync_monitorは、指定されたノード上のデータベースが同期されているかどうかを確認するための特別なツールです。 4 | 5 | このツールはデーモンとして使用するか、ワンタイムチェックを実行するために起動することができます。 6 | 7 | ツールの動作原理は次のとおりです： 8 | 9 | 1. 各ブロックには、すべてのトランザクションの変更のハッシュが含まれており、指定されたノードに最後のブロックIDを提供するようにリクエストします。 10 | 2. 次に、すべてのノードからこのIDのブロックをリクエストし、上記のハッシュを比較します。 11 | 3. ハッシュが異なる場合、指定されたコマンドのメールアドレスに同期エラーメッセージが送信されます。 12 | 13 | ## ロケーション {#location} 14 | このツールは `tools/desync_monitor/` ディレクトリにあります。 15 | 16 | ## コマンドプロンプトフラグ {#command-prompt-flags} 17 | 次のフラグをコマンドプロンプトから使用できます： 18 | * confPath - 設定ファイルのパス。デフォルトのファイル名は `config.toml` です。 19 | * nodesList - リクエストされたブロックのノードリスト。カンマで区切られます。デフォルトは `127.0.0.1:7079` です。 20 | * daemonMode - デーモンとして起動し、N秒ごとに認証が必要な場合に使用する必要があります。デフォルトではこのフラグは `false` に設定されています。 21 | * queryingPeriod - ツールがデーモンとして起動された場合、このパラメータはチェック間隔（秒単位）を設定します。デフォルトは `1` 秒です。 22 | * alertMessageTo - 同期警告エラーが送信されるメールアドレスです。 23 | * alertMessageSubj - 警告メッセージの件名。デフォルトでは `node synchronization` 問題です。 24 | * alertMessageFrom - メッセージが送信されたアドレス。 25 | * smtpHost - メール送信に使用するSMTPサーバーホスト。デフォルトでは `""` です。 26 | * smtpPort - メールメッセージの送信に使用するSMTPサーバーポート。デフォルトでは `25` です。 27 | * smtpUsername - SMTPサーバーのユーザー名。デフォルトでは `""` です。 28 | * smtpPassword - SMTPサーバーのパスワード。デフォルトでは `""` です。 29 | 30 | ## 設定 {#configuration} 31 | このツールはtoml形式の設定ファイルを使用します。 32 | 33 | デフォルトでは、バイナリファイルを起動するフォルダ内のconfig.tomlファイルを探します。 34 | 35 | ファイルパスはconfigPathフラグで変更できます。 36 | 37 | 38 | ``` 39 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 40 | 41 | [daemon] 42 | daemon = false 43 | querying_period = 1 44 | 45 | [alert_message] 46 | to = "" 47 | subject = "problem with xxx nodes" 48 | from = "" 49 | 50 | [smtp] 51 | host = "" 52 | port = 25 53 | username = "" 54 | password = "" 55 | ``` 56 | 57 | ### nodes_list {#nodes-list} 58 | * nodes_list - 情報をリクエストするノード（ホスト）のリスト。 59 | 60 | ### [daemon] {#daemon} 61 | デーモンモードの設定。 62 | * daemon_mode - ツールがデーモンとして動作し、同期チェックを実行します。 63 | * querying_period - 同期チェック間の時間間隔。 64 | 65 | ### [alert_message] {#alert-message} 66 | 警告メッセージのパラメータ。 67 | * to - 同期エラー警告メッセージの受信者のメールアドレス； 68 | * subject - メッセージの件名； 69 | * from - 送信者のメールアドレス。 70 | 71 | ### [smtp] {#smtp} 72 | シンプルメール転送プロトコル（SMTP）サーバーのパラメーターで、同期エラーメッセージの送信に使用されます。 73 | * host - SMTPサーバーのホスト； 74 | * port - SMTPサーバーのポート； 75 | * username - SMTPサーバーのユーザー名； 76 | * password - SMTPサーバーのパスワード。 77 | -------------------------------------------------------------------------------- /docs/ja/topics/daemons.md: -------------------------------------------------------------------------------- 1 | 2 | # デーモン {#daemon} 3 | 4 | このセクションでは、技術的な観点からIBaxノード同士がどのように相互作用するかについて説明します。 5 | 6 | ## サーバーデーモンについて {#about-the-server-daemon} 7 | サーバーデーモンは、ネットワークノード上で実行される必要があります。これはさまざまなサーバー機能を実行し、IBaxのブロックチェーンプロトコルをサポートします。ブロックチェーンネットワークでは、デーモンはブロックやトランザクションの配布、新しいブロックの生成、受信したブロックやトランザクションの検証を行い、フォークの問題を回避することができます。 8 | 9 | ### 名誉ノードデーモン {#honor-node-daemon} 10 | 名誉ノードは次のサーバー デーモンを実行します。 11 | 12 | * [BlockGenerator daemon](#blockgenerator-daemon) 13 | 14 | 新しいブロックを生成します。 15 | 16 | * [BlockCollection daemon](#blockcollection-daemon) 17 | 18 | 他のノードから新しいブロックをダウンロードします。 19 | 20 | * [Confirmations daemon](#confirmations-daemon) 21 | 22 | ノード上のブロックが他のほとんどのノードにも存在することを確認します。 23 | 24 | * [Disseminator daemon](#disseminator-daemon) 25 | 26 | トランザクションとブロックを他の信頼ノードに配布します。 27 | 28 | * QueueParserBlocks daemon 29 | 30 | キュー内のブロックで、他のノードからのブロックを含みます。 31 | 32 | ブロック処理ロジックは[BlockCollection daemon](#blockcollection-daemon)と同じです。 33 | 34 | * QueueParserTx daemon 35 | 36 | キュー内のトランザクションを検証します。 37 | 38 | * Scheduler daemon 39 | 40 | スケジュールされた契約を実行します。 41 | 42 | ### ガーディアンノードデーモン {#guardian-node-daemon} 43 | 44 | ガーディアンノードは以下のサーバーデーモンを実行します： 45 | 46 | 47 | * [BlockCollection daemon](#blockcollection-daemon) 48 | * [Confirmations daemon](#confirmations-daemon) 49 | * [Disseminator daemon](#disseminator-daemon) 50 | * QueueParserTx 51 | * Scheduler 52 | 53 | ## BlockCollection daemon {#blockcollection-daemon} 54 | 55 | このデーモンはブロックをダウンロードし、他のネットワークノードとブロックチェーンを同期します。 56 | 57 | ### ブロックチェーンの同期 {#blockchain-synchronization} 58 | 59 | このデーモンは、ブロックチェーンネットワーク内の最大ブロック高さを決定し、新しいブロックを要求し、ブロックチェーンのフォーク問題を解決することで、ブロックチェーンを同期します。 60 | 61 | #### ブロックチェーンの更新を確認する {#check-for-blockchain-updates} 62 | 63 | このデーモンは、現在のブロックIDからすべての信頼ノードにリクエストを送信します。 64 | 65 | デーモンを実行しているノードの現在のブロックIDが、どの信頼ノードの現在のブロックIDよりも小さい場合、ブロックチェーンネットワークノードは時代遅れと見なされます。 66 | 67 | #### 新しいブロックをダウンロードする {#download-new-blocks} 68 | 69 | 最大の現在のブロック高さを返すノードが最新のノードと見なされます。 70 | デーモンは、すべての未知のブロックをダウンロードします。 71 | 72 | #### フォーク問題の解決 {#solving-the-fork-issue} 73 | 74 | ブロックチェーンでフォークが検出された場合、デーモンは共通の親ブロックまでブロックをダウンロードしてフォークを後退させます。 75 | 共通の親ブロックが見つかったら、デーモンを実行しているノードでブロックチェーンのロールバックが行われ、最新のブロックが含まれるまで正しいブロックがブロックチェーンに追加されます。 76 | 77 | ### テーブル {#tables-1} 78 | 79 | BlocksCollectionデーモンは次のテーブルを使用します： 80 | 81 | * block_chain 82 | * transactions 83 | * transactions_status 84 | * info_block 85 | 86 | 87 | ### リクエスト {#request-1} 88 | 89 | BlockCollectionデーモンは、他のデーモンに対して次のリクエストを送信します： 90 | 91 | * [Type 10](#type-10)は、すべての信頼ノードの中で最大のブロックIDを指します。 92 | * [Type 7](#type-7)は、最大のブロックIDを持つデータを指します。 93 | 94 | ## BlockGenerator daemon {#blockgenerator-daemon} 95 | 96 | BlockGeneratorデーモンは新しいブロックを生成します。 97 | 98 | ### 事前検証 {#pre-verification} 99 | 100 | BlockGeneratorデーモンは、ブロックチェーンの最新ブロックを分析して新しいブロック生成計画を立てます。 101 | 102 | 以下の条件が満たされている場合、新しいブロックを生成できます： 103 | 104 | * 最新のブロックを生成したノードが、信頼ノードリスト内のノードであり、デーモンを実行していること。 105 | * 最新の未検証ブロックが生成されてからの経過時間が最も短いこと。 106 | 107 | ### ブロック生成 {#block-generation} 108 | 109 | デーモンによって生成される新しいブロックには、他のノードの[Disseminatorデーモン](#disseminator-daemon)から受け取ることができるすべての新しいトランザクションが含まれます。また、デーモンを実行しているノードで生成されることもあります。生成されたブロックは、ノードのデータベースに保存されます。 110 | 111 | 112 | ### テーブル {#tables-2} 113 | 114 | BlockGeneratorデーモンは以下のテーブルを使用します： 115 | 116 | * block_chain（新しいブロックを保存する） 117 | * transactions 118 | * transactions_status 119 | * info_block 120 | 121 | ### リクエスト {#request-2} 122 | 123 | BlockGeneratorデーモンは他のデーモンに対してリクエストを行いません。 124 | 125 | ## Disseminatorデーモン {#disseminator-daemon} 126 | 127 | Disseminatorデーモンは、トランザクションとブロックをすべての信頼ノードに送信します。 128 | 129 | ### ガーディアンノード {#guardian-node} 130 | 131 | ガーディアンノードで作業している場合、デーモンはノードで生成されたトランザクションをすべての信頼ノードに送信します。 132 | 133 | ### 信頼ノード {#honor-node} 134 | 135 | 信頼ノードで作業している場合、デーモンは生成されたブロックとトランザクションのハッシュをすべての信頼ノードに送信します。 136 | 137 | その後、信頼ノードは自身が知らないトランザクションのリクエストに応答します。デーモンは完全なトランザクションデータを応答として送信します。 138 | 139 | ### テーブル {#tables-3} 140 | 141 | Disseminatorデーモンは以下のテーブルを使用します： 142 | 143 | * transactions 144 | 145 | ### リクエスト {#request-3} 146 | 147 | Disseminatorデーモンは他のデーモンに対して次のリクエストを送信します： 148 | 149 | * [Type 1](#type-1)：トランザクションとブロックのハッシュを信頼ノードに送信します。 150 | * [Type 2](#type-2)：信頼ノードからトランザクションデータを受信します。 151 | 152 | ## Confirmationsデーモン {#confirmations-daemon} 153 | 154 | Confirmationsデーモンは、自身のノードに存在するすべてのブロックがほとんどの他のノードに存在するかどうかをチェックします。 155 | 156 | ### ブロックの確認 {#block-confirmation} 157 | 158 | ネットワーク内の複数のノードによって確認されたブロックは、確認済みのブロックと見なされます。 159 | 160 | デーモンは、データベース内で現在確認されていない最初のブロックから順番にすべてのブロックを確認します。 161 | 162 | 各ブロックは以下の方法で確認されます： 163 | 164 | * 確認中のブロックのIDを含むリクエストをすべての信頼ノードに送信します。 165 | * すべての信頼ノードがブロックのハッシュに応答します。 166 | * 応答されたハッシュがデーモンノード上のブロックのハッシュと一致する場合、確認カウンタの値が増加します。一致しない場合は、キャンセルカウンタの値が増加します。 167 | 168 | ### テーブル {#tables-4} 169 | 170 | Confirmationsデーモンは以下のテーブルを使用します： 171 | 172 | * confirmation 173 | * info_block 174 | 175 | ### リクエスト {#request-4} 176 | 177 | Confirmationsデーモンは他のデーモンに対して次のリクエストを送信します： 178 | 179 | * [Type 4](#type-4)：信頼ノードからブロックのハッシュをリクエストします。 180 | 181 | ## TCPサービスプロトコル {#tcp-service-protocol} 182 | 183 | TCPサービスプロトコルは、BlocksCollection、Disseminator、Confirmationデーモンへのリクエストにおいて、バイナリプロトコルを使用し、信頼ノードとガーディアンノード上で動作します。 184 | 185 | ## リクエストタイプ {#request-type} 186 | 187 | 各リクエストには、リクエストの最初の2バイトで定義されるタイプがあります。 188 | 189 | 190 | ## Type 1 {#type-1} 191 | 192 | #### リクエスト送信元 {#request-sender-1} 193 | 194 | このリクエストは[Disseminatorデーモン](#disseminator-daemon)によって送信されます。 195 | 196 | #### リクエストデータ {#request-data-1} 197 | 198 | トランザクションとブロックのハッシュ。 199 | 200 | #### リクエスト処理 {#request-processing-1} 201 | 202 | ブロックのハッシュがブロックキューに追加されます。 203 | 204 | トランザクションのハッシュを分析および検証し、ノード上にまだ表示されていないトランザクションを選択します。 205 | 206 | #### レスポンス {#response-1} 207 | 208 | なし。リクエストの処理後、[Type 2](#type-2)のリクエストが発行されます。 209 | 210 | ## Type 2 {#type-2} 211 | 212 | #### リクエスト送信元 {#request-sender-2} 213 | 214 | このリクエストは[Disseminatorデーモン](#disseminator-daemon)によって送信されます。 215 | 216 | #### リクエストデータ {#request-data-2} 217 | 218 | データサイズを含むトランザクションデータ： 219 | 220 | * data_size (4バイト) 221 | 222 | トランザクションデータのバイト数。 223 | 224 | * data (data_sizeバイト) 225 | 226 | トランザクションデータ。 227 | 228 | #### リクエスト処理 {#request-processing-2} 229 | 230 | トランザクションを検証し、トランザクションキューに追加します。 231 | 232 | #### レスポンス {#response-2} 233 | 234 | なし。 235 | 236 | ## Type 4 {#type-4} 237 | 238 | #### リクエスト送信元 {#request-sender-3} 239 | 240 | このリクエストは[Confirmationsデーモン](#confirmations-daemon)によって送信されます。 241 | 242 | #### リクエストデータ {#request-data-3} 243 | 244 | ブロックID。 245 | 246 | #### レスポンス {#response-3} 247 | 248 | ブロックハッシュ。 249 | 250 | このIDのブロックが存在しない場合は`0`を返します。 251 | 252 | ## Type 7 {#type-7} 253 | 254 | #### リクエスト送信元 {#request-sender-4} 255 | 256 | このリクエストは[BlockCollectionデーモン](#blockcollection-daemon)によって送信されます。 257 | 258 | #### Request data {#request-data-4} 259 | 260 | ブロックID。 261 | 262 | * block_id (4 bytes) 263 | 264 | #### レスポンス {#response-4} 265 | 266 | ブロックデータを含む、データサイズを含むレスポンス。 267 | 268 | * data_size (4バイト) 269 | 270 | ブロックデータのバイト数。 271 | 272 | * data (data_sizeバイト) 273 | 274 | ブロックデータ。 275 | 276 | このIDのブロックが存在しない場合、接続は閉じられます。 277 | 278 | ## Type 10 {#type-10} 279 | 280 | #### リクエスト送信元 {#request-sender-5} 281 | 282 | このリクエストは[BlockCollection daemon](#blockcollection-daemon)によって送信されます。 283 | 284 | #### リクエストデータ {#request-data-5} 285 | 286 | なし。 287 | 288 | #### レスポンス {#response-5} 289 | 290 | ブロックID。 291 | 292 | * block_id (4 bytes) 293 | 294 | 295 | -------------------------------------------------------------------------------- /docs/kr/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: 탈중앙화 상업 크로스 체인 인프라 네트워크 6 | actionText: 빠른 시작 → 7 | actionLink: /kr/concepts/about-the-platform.html 8 | features: 9 | - title: 블록체인 애플리케이션 비용 대폭 절감 10 | - title: 독립적으로 구축된 물리적 생태계 11 | - title: 분산 서버, 개발 및 애플리케이션 환경의 신속한 배치 12 | - title: DApp Store 및 BaaS 기능 다양화 13 | - title: 2단계 실제 서비스 응답 14 | - title: 체인 간 및 시스템 간 데이터 상호 작용 15 | - title: 퍼블릭 체인, 얼라이언스 체인, 프라이빗 체인을 통합한 새로운 인프라 네트워크 16 | - title: 사용자 정의 가능한 합의 메커니즘 17 | - title: 다양한 암호화 요구 사항을 충족하기 위한 프런트 엔드와 백엔드 분리 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 07/04/2023 | Built with VuePress 20 | --- 21 | 22 | # IBAX 문서 23 | 24 | ## 개념 25 | * [IBAX 블록체인 플랫폼 개요](concepts/about-the-platform.md) 26 | * [IBAX 블록체인 플랫폼](concepts/blockchain-layers.md) 27 | * [권한 증명 합의](concepts/consensus.md) 28 | * [용어 및 정의](concepts/thesaurus.md) 29 | * [일반적인 문제](concepts/faq.md) 30 | 31 | ## 지도 시간 32 | * [애플리케이션 개발 튜토리얼](tutorials/app_tutorial.md) 33 | * [개발 튜토리얼](tutorials/tutorial.md) 34 | 35 | ## 가이드 36 | * [스마트 계약](topics/script.md) 37 | * [템플릿 언어](topics/templates2.md) 38 | * [컴파일러 및 가상 머신](topics/vm.md) 39 | * [데몬 프로세스](topics/daemons.md) 40 | 41 | 42 | ## 인용하다 43 | * [RESTful API](reference/api2.md) 44 | * [플랫폼 매개변수](reference/platform-parameters.md) 45 | * [서버 구성 파일](reference/backend-config.md) 46 | * [동기화 모니터링 도구](reference/desync_monitor.md) 47 | * [JSON-RPC 애플리케이션 프로그래밍 인터페이스](reference/json-rpc.md) 48 | 49 | ## 전개하다 50 | * [IBAX 블록체인 플랫폼 블록체인 네트워크 구축](howtos/deployment.md) 51 | -------------------------------------------------------------------------------- /docs/kr/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # IBAX는 분산 원장 기술인 블록체인을 기반으로 한 플랫폼입니다. {#the-ibax-network} 2 | 3 | 4 | - [IBAX 네트워크](#the-ibax-network) 5 | - [애플리케이션 개발자](#application-developers) 6 | - [생태계 구성원](#ecolib-members) 7 | - [생태계 애플리케이션 및 플랫폼 애플리케이션](#ecolib-applications-and-platform-applications) 8 | - [하위 모델](#underlying-model) 9 | - [구현](#implementation) 10 | 11 | 12 | 13 | 이 장에서는 IBAX 블록체인 플랫폼의 사용 방법에 대해 설명합니다. 14 | 15 | 만약 IBAX 블록체인 플랫폼에서 애플리케이션을 개발하고 생태계를 관리하는 데 관심이 있다면, IBAX 블록체인 플랫폼에 대해 자세히 알 필요가 없을 수도 있습니다. 16 | 17 | IBAX 블록체인 플랫폼에서는 블록체인과 블록체인 네트워크가 생태계 구성원, 관리자 및 애플리케이션 개발자에게 숨겨져 있습니다. IBAX 블록체인 플랫폼은 모든 이 사용자 그룹을 위해 [RESTful API](../reference/api2.md) 인터페이스를 제공합니다. 이 인터페이스는 블록체인의 무결성을 보장하는 분산 **전역 상태**에 대한 액세스를 제공합니다. 18 | 19 | ## 애플리케이션 개발자 {#application-developers} 20 | 21 | 기술 용어에서 **전역 상태(Global State)**는 데이터 집합입니다. IBAX 블록체인 플랫폼에서 전역 상태는 데이터베이스로 구현됩니다. 응용 프로그램 개발자의 관점에서 응용 프로그램은 이 데이터베이스와 상호 작용하기 위해 쿼리, 삽입 및 업데이트 데이터베이스 테이블을 통해 이루어집니다. 22 | 23 | IBAX 블록체인 플랫폼에서는 계약을 실행하여 거래를 블록체인에 기록합니다. 이러한 거래는 블록체인 네트워크 노드가 실행하는 계약 코드를 호출하며, 이로 인해 전역 상태 데이터베이스가 변경됩니다. 24 | 25 | 응용 프로그램 개발자에게는 계약이 함수와 같은 것으로 간주되며, 계약을 실행할 때 데이터가 데이터베이스에 기록됩니다. 페이지는 스크립트와 같습니다. 페이지 코드는 [페이지 템플릿](../topics/templates2.md) 함수의 집합입니다. 일부 함수는 페이지 요소를 표시하고, 다른 데이터는 데이터베이스에서 가져옵니다. IBAX 블록체인 플랫폼을 사용하는 경우 응용 프로그램 개발자는 거래, 블록 생성 및 합의 알고리즘에 대해 알 필요가 없습니다. 26 | 27 | ## 생태계 구성원 {#ecolib-members} 28 | 29 | 애플리케이션 개발자가 작성한 애플리케이션은 [생태계](../concepts/thesaurus.md#ecosystem) 환경에서 작동하며, 일반적으로 특정 목적을 위해 여러 애플리케이션을 결합하여 해당 목적의 다양한 측면을 달성합니다. 30 | 31 | 생태계의 애플리케이션에 접근하려면 사용자는 해당 생태계의 구성원이어야 합니다. 한 사용자는 여러 생태계의 구성원이 될 수 있습니다. 32 | 33 | 생태계 구성원은 일반적인 웹 애플리케이션과 마찬가지로 애플리케이션 페이지에서 데이터베이스를 보고 수정할 수 있으며, 양식을 작성하고 버튼을 클릭하며 페이지를 탐색할 수 있습니다. 34 | 35 | ## 생태계 애플리케이션과 플랫폼 애플리케이션 {#ecolib-applications-and-platform-applications} 36 | 37 | 응용 프로그램은 **생태계 응용 프로그램**과 **플랫폼 응용 프로그램**으로 범위별로 분류될 수 있습니다. 38 | 39 | > 생태계 응용 프로그램 40 | 41 | 생태계 응용 프로그램은 특정 생태계의 고유한 기능이나 비즈니스 프로세스를 구현합니다. 생태계 응용 프로그램은 해당 생태계에서만 사용할 수 있습니다. 42 | 43 | > 플랫폼 응용 프로그램 44 | 45 | 플랫폼 응용 프로그램은 모든 생태계에 적용될 수 있습니다. 어떤 응용 프로그램이든 플랫폼 응용 프로그램으로 개발할 수 있습니다. IBAX 블록체인 플랫폼 개발자는 투표, 알림, 생태계 구성원 역할 관리 등의 생태계 거버넌스 핵심 기능을 지원하는 플랫폼 응용 프로그램을 제공합니다. 46 | 47 | ## 하위 모델 {#underlying-model} 48 | 49 | > 계층 정의 50 | 51 | IBAX 블록체인 플랫폼은 여러 계층으로 구성됩니다: 52 | 53 | > - 사용자 상호작용 계층 54 | > 55 | > > 생태계 구성원은 페이지와 페이지 요소를 통해 애플리케이션과 상호작용합니다. 56 | > 57 | > - 애플리케이션 계층 58 | > 59 | > > 애플리케이션 개발자는 계약 코드와 페이지 코드를 사용하여 전역 상태(데이터베이스 테이블)와 상호작용합니다. 60 | > 61 | > - 전역 상태 계층 62 | > 63 | > > 분산 작업 분류장부(블록체인)에 기록된 작업을 통해 전역 상태(데이터베이스)를 업데이트하고 동기화합니다. 64 | > 65 | > - 블록체인 계층 66 | > 67 | > > 새로운 블록을 사용하여 분산 작업 분류장부를 업데이트합니다. 새로운 블록에는 작업(트랜잭션)이 전역 상태에서 실행되어야 합니다. 68 | > 69 | > - 노드 네트워크 계층 70 | > 71 | > > IBAX 블록체인 플랫폼 네트워크 프로토콜을 구현합니다. 네트워크 프로토콜은 트랜잭션을 노드 네트워크에서 배포하고 검증하며 새로운 블록을 생성합니다. 마찬가지로, 새로운 블록은 노드 네트워크에서 배포되고 검증됩니다. 모든 노드의 분산 작업 분류장부는 동기화됩니다. 노드 간에 충돌이 발생하면 어떤 블록체인이 유효한 체인으로 간주되고 무효한 블록체인이 롤백되는지를 노드가 인식합니다. 72 | > 73 | > - 트랜잭션 계층 74 | > 75 | > > 트랜잭션은 블록 생성과 블록체인 프로토콜의 기반이 되며, 트랜잭션 자체는 사용자 상호작용 계층에서 실행되는 작업의 결과입니다. 트랜잭션은 Weaver에 의해 생성됩니다. 사용자나 개발자가 페이지의 버튼을 클릭하거나 계약을 코드 편집기에서 실행하는 등의 작업을 수행할 때, Weaver는 이 작업을 트랜잭션으로 변환하고 해당 네트워크 노드에 전송합니다. 76 | 77 | 그러므로 거래 프로세스 방향은 다음과 같습니다: 78 | 79 | - 사용자 페이지에서 사용자 작업이 거래를 생성합니다. 80 | - 해당 거래는 블록에 포함됩니다. 81 | - 해당 블록은 블록체인에 포함됩니다. 82 | - 변경 작업은 블록체인의 전역 상태를 변경시키며, 이 작업은 데이터베이스에 적용됩니다. 83 | - 데이터베이스 변경은 애플리케이션에서 표시됩니다. 84 | 85 | ## 구현 {#implementation} 86 | 87 | IBAX 블록체인 플랫폼은 두 가지 주요 구성 요소로 구성됩니다. 서버 측 [go-ibax](https://github.com/IBAX-io/go-ibax) 와 [Weaver 소스 코드](https://github.com/IBAX-io/weaver) 입니다. 88 | 89 | Weaver: 90 | > - 사용자 페이지 제공 91 | > - 애플리케이션 개발을 위한 IDE 제공 92 | > - 사용자 계정의 공개 키를 저장하고 권한을 실행 93 | > - 애플리케이션 페이지에서 데이터베이스 데이터를 요청하고 사용자에게 애플리케이션 페이지를 표시 94 | > - [REST API](../reference/api2.md) 를 통해 트랜잭션을 서버로 전송 95 | > > 사용자가 작업을 쉽게 수행할 수 있도록 자동으로 트랜잭션을 생성하며, 애플리케이션 개발자가 IDE에서 스마트 컨트랙트를 실행할 때 Weaver는 해당 작업을 트랜잭션으로 변환합니다. 96 | 97 | 서버: 98 | > - 노드의 전역 상태(데이터베이스) 유지 99 | > - 블록체인 프로토콜 구현 100 | > - [가상 머신](../topics/vm.md) 에서 스마트 컨트랙트 코드 실행 101 | > - [템플릿 엔진](../topics/templates2.md) 에서 페이지 코드 실행 102 | > - [RESTful API](../reference/api2.md) 인터페이스 구현 103 | -------------------------------------------------------------------------------- /docs/kr/concepts/consensus.md: -------------------------------------------------------------------------------- 1 | 2 | # 분산된 권한 증명(Proof-of-Authority) 합의 {#decentralized-proof-of-authority-consensus} 3 | 4 | * 분산된 권한 증명 합의란 무엇인가요? 5 | 6 | * DPoA 합의의 장점 7 | 8 | * DPoA 합의와 일반적인 공격 수단 9 | 10 | * IBAX에서의 DPoA 합의 구현 11 | 12 | 이 섹션에서는 분산된 권한 증명 합의인 DPoA의 개념과 IBAX에서의 구현에 대해 설명하겠습니다. 13 | 14 | - [분산 Proof-of-Authority 콘센서스란?](#what-is-decentralized-proof-of-authority-consensus) 15 | - [DPoA 콘센서스의 장점](#advantages-of-dpoa-consensus) 16 | - [DPoA 콘센서스와 일반적인 공격 수단](#dpoa-consensus-and-common-means-of-attack) 17 | - [DoS 공격](#dos) 18 | - [51% 공격](#percent-attack-51) 19 | - [IBAX에서 DPoA 콘센서스의 구현](#implementation-of-dpoa-consensus-in-ibax) 20 | - [Honor 노드](#honor-node) 21 | - [Leader 노드](#leader-node) 22 | - [새로운 블록 생성](#generation-of-new-blocks) 23 | - [포크(Forks)](#forks) 24 | 25 | 26 | ## 분산 Proof-of-Authority 콘센서스란? {#what-is-decentralized-proof-of-authority-consensus} 27 | 28 | IBAX 네트워크는 상업 응용 시나리오와 실제 환경을 고려하여 분산된 권한 증명(DPoA, Decentralized Proof of Authority)이라는 새로운 합의 메커니즘을 구축했습니다. 29 | 30 | 분산화는 우리의 확고한 신념이었습니다. 이는 단순히 IBAX의 인프라 네트워크 환경을 의미하는 것뿐만 아니라, IBAX 네트워크에서 생성된 각 ecoLib에 분산화를 뿌리내리고 기술적인 솔루션을 사용하여 각 ecoLib에서 고도의 자체 조정을 실현하기 위한 것입니다. 고도로 분산된 자체 조정을 위해 전체 아키텍처와 기술적인 구현에서 많은 변경을 가했습니다. 그러나 실제로는 중앙집중식 관리 개념을 피할 수 없습니다. 중앙집중화와 분산화 사이의 균형을 찾기 위해 DPoA 합의 메커니즘 외에도 특정 보상 및 인센티브 프로그램을 마련했습니다. 31 | 32 | IBAX 네트워크는 분산화, 약간의 중앙집중화, 그리고 인증 기관을 결합한 새로운 합의 메커니즘인 DPoA(Decentralized Proof of Authority)를 생성했습니다. 이는 IBAX 공공 네트워크뿐만 아니라 각 사용자와 사용자 그룹이 생성한 ecoLibs에도 적용됩니다. 이로써 완전히 자체 조정되고 분산된, 공정하고 투명하며 부정 방지가 가능한 탈중앙화 자율 조직(DAO)가 생성됩니다. 33 | 34 | DPoA는 네트워크 공격에 대한 방지 메커니즘을 가지며, 네트워크를 보호하고 새로운 IBXC 코인을 생성하는 Mint 노드를 생성할 수 있습니다. IBAXCoin 소지자는 Mint & Stake Emission 보상을 위해 IBXC 유동성 잔액의 일부를 Mint 노드에 스테이킹할 수 있습니다. Minting과 staking은 공격의 비용과 난이도를 증가시키고 IBXC 코인의 총 가치를 비례적으로 증가시키는 역할을 합니다. 이 메커니즘을 통해 어떤 공격의 발생 확률과 피해는 무한히 가까운 제로에 수렴하게 됩니다. 35 | 36 | 37 | ## DPoA 콘센서스의 장점 {#advantages-of-dpoa-consensus} 38 | 39 | Proof-of-Authority (PoA) 합의와 비교하여, DPoA 합의는 다음과 같은 이점을 가지고 있습니다: 40 | 41 | * 고성능 하드웨어가 필요하지 않습니다. PoW 합의와 비교하여, DPoA 합의를 구현하는 노드는 복잡한 수학 논리 작업을 해결하기 위해 계산 리소스를 소비하지 않습니다. 42 | 43 | * 새로운 블록 생성 간격이 예측 가능합니다. 반면 PoW 및 PoS 합의의 경우 각각 다른 시간 간격이 필요합니다. 44 | 45 | * 높은 거래 처리량을 갖습니다. 인가된 네트워크 노드에 의해 지정된 시간 간격으로 순차적으로 블록이 생성되므로 거래 확인 속도가 빨라집니다. 46 | 47 | * 51%의 노드가 손상되지 않는 한 손상된 노드와 악의적인 노드에 대한 허용성이 있습니다. IBAX는 노드를 차단하고 블록 생성 권한을 취소하는 메커니즘을 구현합니다. 48 | 49 | ## DPoA 콘센서스와 일반적인 공격 수단 {#dpoa-consensus-and-common-means-of-attack} 50 | 51 | ### DoS {#dos} 52 | 53 | 공격자는 대상 노드로 대량의 거래와 블록을 보내서 그 작동을 방해하고 서비스를 사용할 수 없게 만들려고 할 수 있습니다. 54 | 55 | DPoA 메커니즘은 DoS 공격에 대항할 수 있습니다: 56 | 57 | * 네트워크 노드가 미리 인증되었기 때문에, DoS 공격을 견딜 수 있는 노드에게만 블록 생성 권한을 부여할 수 있습니다. 58 | 59 | * 특정 기간 동안 honor 노드가 사용 불가능하면 honor 노드 목록에서 제외될 수 있습니다. 60 | 61 | ### 51% 공격 {#percent-attack-51} 62 | 63 | DPoA 합의 방식의 경우, 51% 공격은 공격자가 네트워크 노드의 51%를 통제해야 합니다. 그러나 PoW 합의 방식의 경우, 공격자는 네트워크의 51% 계산 성능을 획득해야 합니다. 허가된 블록체인 네트워크에서 노드 통제를 얻는 것은 계산 성능 획득보다 훨씬 어렵습니다. 64 | 65 | 예를 들어, PoW 합의 방식을 구현한 네트워크에서는 공격자가 제어하는 네트워크 세그먼트의 계산 성능(성능)을 증가시켜 통제하는 노드의 비율을 높일 수 있습니다. 하지만 DPoA 합의 방식에서는 노드의 계산 성능이 블록체인 네트워크 결정에 영향을 미치지 않기 때문에 이는 의미가 없습니다. 66 | 67 | ## IBAX에서 DPoA 콘센서스의 구현 {#implementation-of-dpoa-consensus-in-ibax} 68 | 69 | ### Honor 노드 {#honor-node} 70 | 71 | IBAX에서는 온라인 노드만이 새로운 블록을 생성할 수 있으며, 이 노드들은 블록체인 네트워크와 분산 원장을 유지합니다. 72 | 73 | 온라인 노드 목록은 블록체인 레지스트리에 저장되며, 노드의 순서는 노드들이 새로운 블록을 생성하는 순서를 결정합니다. 74 | 75 | ### Leader 노드 {#leader-node} 76 | 77 | 다음 공식은 현재 **리더 노드**를 결정합니다. 즉, 현재 시간에 새로운 블록을 생성해야하는 노드입니다. 78 | 79 | ``` 80 | leader = ((time - first) / step) % nodes 81 | ``` 82 | 83 | > leader 84 | 85 | Current leader node. 86 | 87 | > time 88 | 89 | Current time (UNIX). 90 | 91 | > first 92 | 93 | First block generation time (UNIX). 94 | 95 | > step 96 | 97 | Number of seconds in the block generation interval. 98 | 99 | > nodes 100 | 101 | Total number of honor nodes. 102 | 103 | ### 새로운 블록 생성 {#generation-of-new-blocks} 104 | 105 | 새로운 블록은 현재 시간 간격의 [리더 노드](#leader-node) 에 의해 생성됩니다. 각 시간 간격에서 리더 역할은 명예 노드 목록에서 다음 명예 노드로 전달됩니다. 106 | 107 | ![avatar](/block-generation.png) 108 | 109 | a) 새로운 블록 생성을 위한 단계 110 | 111 | 새로운 블록을 생성하기 위한 주요 단계는 다음과 같습니다: 112 | 113 | 1. 노드의 트랜잭션 큐에서 모든 새로운 트랜잭션을 수집합니다. 114 | 115 | 2. 트랜잭션을 하나씩 실행합니다. 잘못된 또는 실행할 수 없는 트랜잭션은 거부됩니다. 116 | 117 | 3. [블록 생성 제한](../reference/platform-parameters.md#configure-the-generation-of-blocks) 이 준수되는지 확인합니다. 118 | 119 | 4. 유효한 트랜잭션으로 블록을 생성하고, 온라인 노드의 개인 키를 사용하여 ECDSA 알고리즘으로 블록에 서명합니다. 120 | 121 | 5. 이 블록을 다른 온라인 노드들에게 전송합니다. 122 | 123 | b) 새 블록 확인 124 | 125 | 다른 명예 노드에서 새 블록을 확인하는 단계: 126 | 127 | 1. 새로운 블록을 수신하고 다음을 확인합니다: 128 | 129 | - 새로운 블록이 현재 간격의 리더 노드에 의해 생성되었는지 여부를 확인합니다. 130 | 131 | - 현재 간격의 리더 노드에 의해 생성된 다른 블록이 있는지 확인합니다. 132 | 133 | - 새로운 블록이 올바르게 서명되었는지 확인합니다. 134 | 135 | 2. 블록에서 트랜잭션을 하나씩 실행합니다. 트랜잭션이 성공적으로 실행되었는지 및 [블록 생성 제한](../reference/platform-parameters.md#configure-the-generation-of-blocks) 내에서 수행되었는지 확인합니다. 136 | 137 | 3. 이전 단계에 따라 블록을 추가하거나 거부합니다: 138 | 139 | - 블록 유효성 검증이 성공적인 경우, 새로운 블록을 현재 노드의 블록체인에 추가합니다. 140 | 141 | - 블록 유효성 검증이 실패한 경우, 블록을 거부하고 **bad block** 트랜잭션을 전송합니다. 142 | 143 | - 이러한 잘못된 블록을 생성한 온라인 노드가 계속해서 잘못된 블록을 생성하는 경우, 해당 노드를 차단하거나 온라인 노드 목록에서 제외할 수 있습니다. 144 | 145 | ### 포크 {#forks} 146 | 147 | **포크**는 블록체인의 다른 부분과 독립적으로 생성된 하나 이상의 블록을 포함하는 대체 블록체인의 버전입니다. 148 | 149 | 포크는 네트워크 일부가 동기화되지 않을 때 발생하는 경우가 일반적입니다. 높은 네트워크 대기 시간, 의도적 또는 무의식적인 시간 제한 위반, 노드에서의 시간 비동기화 등이 포크의 원인일 수 있습니다. 네트워크 노드가 상당한 지리적 분포를 가지고 있다면, 블록 생성 간격을 늘려야 합니다. 150 | 151 | 포크는 가장 긴 블록체인 규칙을 따르는 방식으로 해결됩니다. 두 개의 블록체인 버전이 감지되면, 온라인 노드는 더 짧은 블록체인을 롤백하고 더 긴 블록체인을 받아들입니다. 152 | 153 | ![avatar](/block-fork-resolution.png) -------------------------------------------------------------------------------- /docs/kr/concepts/faq.md: -------------------------------------------------------------------------------- 1 | 2 | # 자주 묻는 질문 (FAQ) 3 | 4 | - [1. IBAX를 간단히 설명해주세요.](#question-1) 5 | - [2. IBAX는 비트코인, 이더리움 또는 다른 블록체인에 적용 가능한가요?](#question-2) 6 | - [3. IBAX와 내장된 스마트 계약 실행 메커니즘을 갖춘 다른 공개 블록체인 플랫폼의 주요 차이점은 무엇인가요?](#question-3) 7 | - [4. 자체 암호화폐가 있나요?](#question-4) 8 | - [5. 명예 노드란 무엇이며, 누가 유지할 수 있나요?](#question-5) 9 | - [6. 플랫폼 생태계란 무엇인가요?](#question-6) 10 | - [7. 누가 생태계를 만들 수 있나요?](#question-7) 11 | - [8. 사용자는 어떻게 생태계 회원이 되나요?](#question-8) 12 | - [9. 하나의 사용자가 여러 생태계를 만들 수 있나요?](#question-9) 13 | - [10. 플랫폼 애플리케이션이란 무엇인가요?](#question-10) 14 | - [11. 어떤 프로그래밍 언어를 사용하여 애플리케이션을 만드나요?](#question-11) 15 | - [12. 어떤 소프트웨어를 사용하여 애플리케이션을 만들고 사용자와 상호작용하나요?](#question-12) 16 | - [13. 플랫폼 계약은 데이터에 액세스하기 위해 제3자 API를 사용할 수 있나요?](#question-13) 17 | - [14. 블록체인에 저장된 계약을 변경할 수 있나요?](#question-14) 18 | - [15. 스마트 로우란 무엇인가요?](#question-15) 19 | - [16. 계약이 다른 계약을 호출하고 실행할 수 있나요?](#question-16) 20 | - [17. 애플리케이션은 마스터 계약과 함께 실행되나요?](#question-17) 21 | - [18. 애플리케이션을 다른 언어로 지역화할 수 있나요?](#question-18) 22 | - [19. 템플릿 언어를 사용하지 않고 페이지를 만들 수 있나요?](#question-19) 23 | - [20. 페이지는 블록체인에 저장되나요?](#question-20) 24 | - [21. 계약 작업에 사용할 수 있는 데이터베이스 유형은 무엇인가요?](#question-21) 25 | - [22. 데이터베이스 테이블의 데이터 액세스를 어떻게 관리하나요?](#question-22) 26 | - [23. 생태계의 애플리케이션은 다른 생태계의 다른 애플리케이션과 데이터를 교환할 수 있나요?](#question-23) 27 | - [24. 새로운 생태계의 모든 애플리케이션은 처음부터 작성해야 하나요?](#question-24) 28 | - [25. 애플리케이션 운영에 대한 수수료가 있나요?](#question-25) 29 | - [26. 애플리케이션 운영비는 누가 지불하나요?](#question-26) 30 | - [27. 취약점으로 인한 공격으로부터 생태계의 애플리케이션을 어떻게 보호하나요?](#question-27) 31 | - [28. 앞으로의 계획에서 어떤 새로운 기능이 구현될 예정인가요?](#question-28) 32 | - [29. 운영 가능성을 증명하는 방법은 무엇인가요?](#question-29) 33 | 34 | ## 1. IBAX 블록체인 플랫폼에 대해 간단히 설명해주세요. {#question-1} 35 | 36 | - IBAX는 통합 응용 프로그램 개발 환경을 기반으로 한 디지털 생태계를 구축하기 위한 블록체인 플랫폼입니다. 이 환경은 데이터, 인터페이스 및 스마트 계약 액세스 권한을 관리하기 위한 다중 수준 권한 시스템을 갖추고 있습니다. 37 | 38 | ## 2. IBAX 블록체인 플랫폼은 비트코인, 이더리움 또는 다른 블록체인에 적용될 수 있나요? {#question-2} 39 | 40 | - 아닙니다. IBAX 블록체인 플랫폼은 자체 원본 블록체인 위에 구축됩니다. 41 | 42 | ## 3. 내장된 스마트 계약 실행 메커니즘을 갖춘 다른 공공 블록체인 플랫폼과의 주요 차이점은 무엇인가요? {#question-3} 43 | 44 | - IBAX 블록체인 플랫폼은 다음과 같은 고유한 기능을 갖추고 있습니다: 45 | - 통합 응용 프로그램 개발 환경을 단일 클라이언트 소프트웨어에서 구현합니다. 46 | - 페이지 디자인에 사용되는 전용 템플릿 언어 Logicor와 계약 언어 Needle이 상호 조화를 이룹니다. 47 | - 멤버, 역할 및 계약에 권한을 부여할 수 있는 다중 수준 권한 시스템을 갖추고 있습니다. 48 | - 블록체인 애플리케이션을 생성하고 사용자와 상호 작용하는 자치 소프트웨어 환경을 위한 생태계를 갖추고 있습니다. 49 | - 문제 해결을 위한 프로토콜 매개 변수 변경을 정의하는 특수 스마트 계약인 스마트 법률을 사용하는 법률 체계를 갖추고 있습니다. 50 | 51 | ## 4. 자체 암호화폐를 갖고 있나요? {#question-4} 52 | 53 | - 예, IBAX 블록체인 플랫폼은 자체 블록체인 기반 토큰인 IBXC를 사용합니다. 54 | 55 | ## 5. 명예 노드란 무엇이며, 누가 유지할 수 있나요? {#question-5} 56 | 57 | - 명예 노드는 거래를 검증하고 새로운 블록을 생성할 수 있는 네트워크 노드입니다. 58 | - 처리 능력과 장애 허용 능력이 충분한 모든 네트워크 노드가 명예 노드가 될 수 있습니다. 59 | - IBAX 블록체인 플랫폼은 권한 증명(DPoA) 합의 메커니즘을 사용하며, 노드는 생태계의 투표에 기반하여 검증 노드가 될 수 있습니다. 60 | - 그러나 플랫폼 토큰 소유자에 의해 정상적인 운영 능력이 증명된 생태계만이 이러한 투표에 참여할 수 있습니다. 61 | - 이러한 권한 기반 알고리즘을 사용하여 명예 노드는 주요한 생태계 운영자로서 네트워크를 유지합니다. 62 | 63 | ## 6. 플랫폼 생태계란 무엇인가요? {#question-6} 64 | 65 | - 생태계는 블록체인 애플리케이션을 생성하고 사용자의 작업을 위한 자치 소프트웨어 환경입니다. 66 | 67 | ## 7. 누가 생태계를 생성할 수 있나요? {#question-7} 68 | 69 | - 플랫폼의 모든 사용자가 새로운 생태계를 생성할 수 있습니다. 70 | 71 | ## 8. 사용자는 어떻게 생태계의 구성원이 될 수 있나요? {#question-8} 72 | 73 | - 플랫폼 네트워크의 생태계 구성원 등록은 기존 생태계에서 이루어집니다. 생태계의 정책은 새로운 생태계의 주요 공개 정보를 전문적인 생태계 디렉토리에 게시합니다. 74 | 75 | ## 9. 한 사용자가 여러 개의 생태계를 생성할 수 있나요? {#question-9} 76 | 77 | - 네, 각 사용자는 임의의 수의 생태계를 생성할 수 있으며, 여러 생태계의 구성원이 될 수도 있습니다. 78 | 79 | ## 10. 플랫폼 애플리케이션은 무엇인가요? {#question-10} 80 | 81 | - 애플리케이션은 기능이나 서비스를 구현하는 완전한 소프트웨어 제품입니다. 애플리케이션은 데이터베이스 테이블, 계약 및 페이지로 구성됩니다. 82 | 83 | ## 11. 어떤 프로그래밍 언어를 사용하여 애플리케이션을 만드나요? {#question-11} 84 | 85 | - 스마트 계약은 Needle 언어로 작성되며, 이 언어는 플랫폼 팀에 의해 개발되었습니다. 자세한 내용은 다음을 참조하세요: 86 | [스마트 계약](../topics/script.md) 87 | - 페이지는 Logicor 언어로 작성되며, 이는 페이지 템플릿 언어입니다. 자세한 내용은 다음을 참조하세요: 88 | [템플릿 언어](../topics/templates2.md) 89 | 90 | ## 12. 애플리케이션 및 사용자 상호작용을 위해 어떤 소프트웨어를 사용하나요? {#question-12} 91 | 92 | - 애플리케이션은 Weaver에서 작성하고 실행되며, 다른 소프트웨어는 필요하지 않습니다. 93 | 94 | ## 13. 플랫폼 스마트 계약은 타사 API 인터페이스를 통해 데이터에 접근할 수 있나요? {#question-13} 95 | 96 | - 아닙니다, 스마트 계약은 블록체인에 저장된 데이터에만 직접적으로 접근할 수 있으며, [CLB](about-the-platform.md#虚拟专用生态系统)는 외부 데이터 소스를 처리하는 데 사용됩니다. 97 | 98 | ## 14. 블록체인에 저장된 스마트 계약을 변경할 수 있나요? {#question-14} 99 | 100 | - 네, 스마트 계약은 변경할 수 있습니다. 스마트 계약의 변경 권한은 생성자에 의해 지정되며, 스마트 계약 생성자는 변경을 거부하는 권한을 지정하거나 스마트 계약 및 구성원의 변경을 허용하거나 복잡한 조건 집합을 스마트 법률에 구성할 수 있습니다. 101 | - Weaver는 모든 스마트 계약 버전에 대한 액세스를 제공합니다. 102 | 103 | ## 15. 스마트 법률이란 무엇인가요? {#question-15} 104 | 105 | - 스마트 법률은 일반적인 스마트 계약의 작동을 제어하고 제한하여 생태계 구성원의 활동을 제어하고 제한하기 위한 스마트 계약입니다. 106 | - 일련의 스마트 법률은 생태계의 법적 체계로 간주될 수 있습니다. 107 | 108 | ## 16. 스마트 계약은 다른 스마트 계약을 호출하고 실행할 수 있나요? {#question-16} 109 | 110 | - 네, 스마트 계약은 직접 주소를 찾아가서 매개변수를 제공하거나 링크 이름을 통해 다른 스마트 계약을 호출할 수 있습니다. 자세한 내용은 [스마트 계약](../topics/script.md)을 참조하세요. 111 | 112 | ## 17. 애플리케이션 작업에는 주 스마트 계약이 필요한가요? {#question-17} 113 | 114 | - 필요하지 않습니다. 스마트 계약은 특정 기능을 수행하는 자체 실행 프로그램 모듈입니다. 각 스마트 계약은 지정된 데이터를 수신하고 해당 데이터의 정확성을 확인한 후 일부 작업을 수행하며, 이러한 작업은 트랜잭션으로 기록됩니다. 115 | 116 | ## 18. 애플리케이션을 다른 언어로 지역화할 수 있나요? {#question-18} 117 | 118 | - 가능합니다. Weaver는 내장된 지역화 지원 메커니즘을 갖추고 있어 어떤 언어의 페이지도 생성할 수 있습니다. 119 | 120 | ## 19. 템플릿 언어를 사용하지 않고 페이지를 생성할 수 있나요? {#question-19} 121 | 122 | - 가능합니다. [RESTful API](../reference/api2.md) 를 사용하여 이를 수행할 수 있습니다. 123 | 124 | ## 20. 페이지는 블록체인에 저장되나요? {#question-20} 125 | 126 | - 네, 페이지와 스마트 계약은 모두 블록체인에 저장되어 위조를 방지합니다. 127 | 128 | ## 21. 어떤 유형의 데이터베이스를 스마트 계약 작업에 사용할 수 있나요? {#question-21} 129 | 130 | - 현재는 PostgreSQL 데이터베이스를 사용하고 있습니다. 131 | 132 | ## 22. 데이터 테이블의 데이터 액세스를 어떻게 관리할 수 있나요? {#question-22} 133 | 134 | - 생태계 구성원, 역할 또는 지정된 스마트 계약에 대해 새 필드, 새 항목을 추가하거나 열의 데이터에 대한 권한을 변경할 수 있습니다. 단, 특정 작업을 수행하기 위해 생성된 스마트 계약은 제외됩니다. 135 | 136 | ## 23. 생태계 내 애플리케이션은 다른 생태계에서 온 애플리케이션과 데이터를 교환할 수 있나요? {#question-23} 137 | 138 | - 가능합니다. 모든 생태계에 적용되는 전역 데이터 테이블을 통해 데이터 교환을 조직할 수 있습니다. 139 | 140 | ## 24. 새로운 생태계의 모든 애플리케이션을 처음부터 작성해야 할까요? {#question-24} 141 | 142 | - 그렇지 않습니다. 각 새로운 생태계에는 기본적으로 제공되는 몇 가지 애플리케이션이 있습니다: 143 | - 생태계 구성원 및 역할 관리 메커니즘; 144 | - 추가 토큰의 발행 및 구성; 145 | - 투표 시스템; 146 | - 알림 시스템; 147 | - 생태계 구성원 간의 메시지 통신. 148 | 149 | 이러한 애플리케이션은 특정 생태계의 요구 사항을 충족하기 위해 편집 및 구성할 수 있습니다. 150 | 151 | ## 25. 애플리케이션 운영에는 어떤 비용이 발생하나요? {#question-25} 152 | 153 | - 예, 온플랫폼에서 명예 노드의 리소스를 사용하려면 토큰을 지불해야 합니다. 154 | 155 | ## 26. 애플리케이션 운영 비용을 누가 지불하나요? {#question-26} 156 | 157 | 해당 계정 주소에 의해 지불됩니다. 현재 4가지 방법으로 애플리케이션 운영 비용을 지불할 수 있습니다: 158 | 159 | - 스마트 계약 호출자, 기본 계정 주소, 사용자가 스마트 계약을 호출할 때 해당 사용자의 계정 주소가 지불합니다. 160 | - 스마트 계약 바인더, 스마트 계약을 생성한 사람이 지정한 계정 주소, 스마트 계약을 호출하는 모든 사용자의 비용은 해당 계정 주소가 지불합니다. 161 | - 생태계 생성자, 생태계 내 모든 애플리케이션의 운영 비용은 생태계 생성자가 지불합니다. 162 | - 생태계 전용 지갑, 각 생태계에는 고유한 계정 주소가 있으며, 생태계 생성자가 해당 계정 주소를 활성화하면 생태계 내 모든 애플리케이션의 운영 비용은 해당 계정 주소가 지불합니다. 163 | 164 | 지불 우선 순위: *생태계 전용 지갑* > *생태계 생성자* > *스마트 계약 바인더* > *스마트 계약 호출자*. 165 | 166 | ## 27. 생태계 내 응용 프로그램이 취약점 공격으로부터 보호되는 방법은 무엇인가요? {#question-27} 167 | 168 | - 플랫폼 팀은 응용 프로그램 코드에서 오류를 완전히 피할 수 없다는 것을 알고 있습니다. 특히 응용 프로그램은 모든 사용자가 작성할 수 있기 때문에 그렇습니다. 이것이 우리가 취약점 공격의 결과를 제거하는 메커니즘을 구축하기로 결정한 이유입니다. 법적 체계는 응용 프로그램의 공격 작업을 중지하고 일부 거래를 사용하여 원래 상태로 복구할 수 있습니다. 법적 체계에는 이러한 스마트 계약을 실행하는 권한과 이러한 권한을 부여하는 투표 프로세스가 규정되어 있습니다. 169 | 170 | ## 28. 미래 계획에서 어떤 새로운 기능을 구현할 예정인가요? {#question-28} 171 | 172 | - 시각적 스마트 계약 디자이너; 173 | - 혼합 데이터베이스(SQL 및 NoSQL) 지원; 174 | - 다양한 생태계에서의 거래의 병렬 다중 스레드 처리; 175 | - 클라이언트에서 리소스 집약적인 계산 실행; 176 | - 생태계 호스팅 및 계산 능력 교환; 177 | - 가벼운 노드, 서버에 일부 블록만 저장; 178 | - 통합 플랫폼 내 데이터 조작을 위한 의미 참조(온톨로지) 등. 179 | 180 | ## 29. 운용 가능성을 어떻게 입증하나요? {#question-29} 181 | 182 | - IBAX 블록체인 플랫폼에서는 여러 개념 증명 프로젝트와 사례를 구현했습니다. 사회적인 세금 징수 및 전자 세금계산서 생성 및 유통 시스템, 의료기기 감시 및 위조 방지 추적 시스템, 자금 조달 및 감독 시스템, 투표/여론 조사 시스템, 상업 등록, 무역 금융 도구, 자산 등록 스마트 계약 관리 시스템 등이 있습니다. 183 | -------------------------------------------------------------------------------- /docs/kr/concepts/thesaurus.md: -------------------------------------------------------------------------------- 1 | # 术언어와 정의 {#terms-and-definitions} 2 | 3 | - [블록체인 관련 용어](#blockchain-terms) 4 | - [블록체인](#blockchain) 5 | - [P2P (Peer-to-Peer) 네트워크](#peer-to-peer-network) 6 | - [해시](#hash) 7 | - [블록](#block) 8 | - [블록 검증](#block-verification) 9 | - [합의](#consensus) 10 | - [토큰](#token) 11 | - [식별자](#identification) 12 | - [고유 식별자](#unique-identification) 13 | - [개인 키](#private-key) 14 | - [공개 키](#public-key) 15 | - [디지털 서명](#digital-signature) 16 | - [스마트 계약](#smart-contract) 17 | - [거래 수수료](#transaction-fee) 18 | - [이중 지불](#double-spend) 19 | - [암호화](#encryption) 20 | - [개인 블록체인](#private-blockchain) 21 | - [공개 블록체인](#public-blockchain) 22 | - [권한 증명](#proof-of-authority) 23 | - [IBAX 블록체인 플랫폼 용어](#ibax-terms) 24 | - [테스트넷](#testnet) 25 | - [메인넷](#mainnet) 26 | - [가스 수수료](#gas-fee) 27 | - [계정 주소](#account-address) 28 | - [지갑 주소](#wallet-address) 29 | - [Weaver](#weaver) 30 | - [생태계](#ecolib) 31 | - [생태계 매개변수](#ecolib-parameters) 32 | - [생태계 구성원](#ecolib-members) 33 | - [가상 개인 생태계](#virtual-private-ecolib) 34 | - [탈중앙화된 권한 증명](#decentralized-proof-of-authority) 35 | - [Needle](#needle) 36 | - [Logicor](#logicor) 37 | - [통합 개발 환경 (IDE)](#integrated-development-environment-ide) 38 | - [페이지 편집기](#page-editor) 39 | - [시각적 페이지 디자이너](#visual-page-designer) 40 | - [스마트 계약 편집기](#contract-editor) 41 | - [다국어 자원](#multilingual-resources) 42 | - [애플리케이션 내보내기](#application-export) 43 | - [애플리케이션 가져오기](#application-import) 44 | - [스마트 법률](#smart-law) 45 | - [법률 체계](#legal-system) 46 | - [애플리케이션](#application) 47 | - [페이지](#page) 48 | - [코드 세그먼트](#code-segment) 49 | - [접근 권한](#access-rights) 50 | - [명예 노드](#honor-node) 51 | - [가디언 노드](#guardian-node) 52 | - [동시 트랜잭션 처리](#concurrent-transaction-processing) 53 | 54 | 55 | 56 | ## 区블록체인 관련 용어 {#blockchain-terms} 57 | 58 | ### 블록체인 {#blockchain} 59 | 60 | 하나의 데이터 저장 및 처리 시스템은 데이터 위조와 손실을 방지하며 데이터 신뢰성을 유지할 수 있습니다. 다음과 같은 방법으로 데이터 보호를 실현합니다: 61 | 62 | 1. 데이터를 암호화된 블록 체인 시리즈에 기록합니다. 63 | 2. 피어 네트워크에서 분산 저장된 블록 체인 복제본을 사용합니다. 64 | 3. 합의 메커니즘을 사용하여 모든 노드의 블록 체인을 동기화합니다. 65 | 4. 데이터 전송 및 처리 계약의 알고리즘을 블록 체인에 저장하여 네트워크에서 데이터 작업을 실행할 때 데이터 신뢰성을 보장합니다. 66 | 67 | ### P2P (Peer-to-Peer) 네트워크 {#peer-to-peer-network} 68 | 69 | 중앙 서버가 없는 컴퓨터 네트워크의 피어 노드로 구성됩니다. 70 | 71 | ### 해시 {#hash} 72 | 73 | > 해시 함수는 임의의 파일이나 데이터 집합의 길이를 짧고 고정된 길이의 이진 값으로 매핑하는 것으로도 알려져 있습니다.。 74 | 75 | ### 블록 {#block} 76 | 77 | > 거래의 형식과 서명을 확인한 후, 영광 노드에 의해 특정 데이터 구조로 그룹화된 거래의 집합입니다. 블록은 이전 블록에 대한 링크로서 해시 포인터를 포함하며, 이는 블록체인의 암호화 보안을 보장하는 조치 중 하나입니다. 78 | 79 | ### 블록 검증 {#block-verification} 80 | 81 | > 블록의 구조, 생성 시간, 이전 블록과의 호환성, 거래 서명 및 거래와 블록 데이터의 일치 여부를 확인하는 것입니다. 82 | 83 | ### 합의 {#consensus} 84 | 85 | > 영광 노드가 블록체인에 새로운 블록을 추가하는 과정에서 사용하는 검증 프로토콜 또는 해당 유형의 알고리즘입니다. 86 | 87 | ### 거래 {#transaction-1} 88 | 89 | > 블록체인 네트워크 상에서 데이터 전송 작업 또는 해당 유형의 거래를 기록하는 것입니다. 90 | 91 | ### 토큰 {#token} 92 | 93 | > 블록체인 상에서 유통되는 암호화된 디지털 권리 증명입니다. 레지스터에 저장된 식별 가능한 숫자 레코드의 집합으로, 이러한 레코드 간 권리 점유를 교환하는 메커니즘을 포함합니다. 94 | 95 | ### 식별자 {#identification} 96 | 97 | > 시스템 내 사용자를 식별하기 위한 암호화 프로그램입니다. 98 | 99 | ### 고유 식별자 {#unique-identification} 100 | 101 | > 계정과 사용자를 연결하는 프로그램으로, 사용자 이름을 실제 사용자와 연결하기 위해 법적 및 조직적인 노력이나 다른 프로그램이 생체 인식을 구현해야 합니다. 102 | 103 | ### 개인 키 {#private-key} 104 | 105 | > 소유자가 보관하는 문자열로, 소유자가 네트워크 상의 가상 계정에 액세스하고 거래에 서명하는 데 사용됩니다. 106 | 107 | ### 공개 키 {#public-key} 108 | 109 | > 개인 키의 진정성을 확인하기 위해 사용되는 문자열로, 공개 키는 개인 키에서 유일하게 파생됩니다. 110 | 111 | ### 디지털 서명 {#digital-signature} 112 | 113 | > 문서나 메시지가 데이터 암호화를 거친 후 얻어지는 속성으로, 디지털 서명은 문서의 무결성(수정되지 않음)과 신뢰성(송신자의 신원 확인)을 확인하는 데 사용됩니다. 114 | 115 | ### 스마트 계약 {#smart-contract} 116 | 117 | > 블록체인에서 데이터 저장 작업을 실행하는 프로그램으로, 모든 계약은 블록체인에 저장됩니다. 118 | 119 | ### 거래 수수료 {#transaction-fee} 120 | 121 | > 영광한 노드에게 거래 실행에 대한 수수료를 지불합니다. 122 | 123 | ### 이중 지불 {#double-spend} 124 | 125 | > 블록체인 네트워크를 공격하는 방법 중 하나로, 한 거래를 두 번 소비하는 결과를 가져옵니다. 126 | > 127 | > 블록체인 분기가 발생할 때 이러한 공격이 발생할 수 있습니다. 이러한 유형의 공격은 공격자가 네트워크의 50% 이상의 검증 능력을 제어할 때만 실행될 수 있습니다. 128 | 129 | ### 암호화 {#encryption} 130 | 131 | > 숫자 데이터를 변환하는 방법으로, 해당 복호화 키를 가진 당사자만이 해당 데이터를 읽을 수 있습니다. 132 | 133 | ### 개인 체인 {#private-blockchain} 134 | 135 | > 단일 조직 (정부, 회사 또는 개인)이 모든 노드와 데이터 액세스 권한을 집중적으로 제어하는 블록체인 네트워크입니다. 136 | 137 | ### 공개 체인 {#public-blockchain} 138 | 139 | > 어떠한 조직의 제어도 받지 않는 블록체인 네트워크로, 모든 결정은 참여자들 간의 합의를 통해 이루어지며, 누구나 블록체인 네트워크의 데이터를 얻고 액세스할 수 있습니다. 140 | 141 | ### 권한 증명 {#proof-of-authority} 142 | 143 | > 권한 증명 (PoA)은 IBAX 네트워크에서 분산, 약간 중앙 집중화 및 인증서 권한을 결합한 새로운 합의 메커니즘입니다. 우리는 이를 PoA (권한 증명)라고 부릅니다. 전체 IBAX 네트워크의 연속성을 보장하기 위해 합의는 IBAX 공공 네트워크뿐만 아니라 각 사용자 및 사용자 그룹이 생성하는 ecoLibs를 포함합니다. 이는 진정한 자치, 탈중앙화, 공정성, 투명성 및 부정 행위 방지를 갖춘 탈중앙화 자치 조직 (DAO)을 생성할 것입니다. 144 | 145 | ## IBAX 블록체인 플랫폼 용어 {#ibax-terms} 146 | 147 | ### 테스트넷 {#testnet} 148 | 149 | > 테스트용 블록체인 네트워크 버전입니다. 150 | 151 | ### 메인넷 {#mainnet} 152 | 153 | > 블록체인 네트워크의 주요 버전입니다. 154 | 155 | ### 거래 트랜잭션 {#transaction-2} 156 | 157 | > 스마트 계약을 호출하고 계약에 매개 변수를 전달하는 작업 명령입니다. 신용 노드가 거래를 실행하여 데이터베이스를 업데이트합니다. 158 | 159 | ### 가스 수수료 {#gas-fee} 160 | 161 | > 노드 네트워크에서 일부 작업을 실행하는 데 필요한 비용을 계산하는 데 사용되는 일반적인 단위입니다. 가스 요율은 신용 노드의 투표에 의해 결정됩니다. 162 | 163 | ### 계정 주소 {#account-address} 164 | 165 | > 토큰을 저장하는 데이터 레코드로, 한 쌍의 키 (개인 키와 공개 키)를 사용하여 액세스할 수 있습니다. 166 | 167 | ### 지갑 주소 {#wallet-address} 168 | 169 | > 사용자의 가상 계정 이름으로, 노드 네트워크에서의 사용자의 문자열 인코딩 식별자입니다. 170 | 171 | ### Weaver {#weaver} 172 | 173 | > 노드 네트워크를 연결하는 데 사용되는 소프트웨어 클라이언트로, 데스크톱 버전과 웹 브라우저 버전이 있습니다. 174 | > 175 | > Weaver는 플랫폼 개발 환경을 통합하여 데이터 테이블, 페이지 및 스마트 계약을 생성하고 편집하는 기능을 제공합니다. 사용자는 Weaver를 사용하여 생태계를 구축하고 애플리케이션을 생성하고 사용할 수 있습니다. 176 | 177 | ### 생태계 {#ecolib} 178 | 179 | > 상대적으로 폐쇄적이거나 개방적인 소프트웨어 프로그래밍 환경으로, 애플리케이션과 생태계 구성원을 포함합니다. 180 | > 181 | > 생태계 구성원은 생태계 전용 토큰을 발행하고 스마트 계약을 사용하여 구성원 간의 상호 작용 규칙을 설정하며, 애플리케이션 요소에 대한 구성원의 액세스 권한을 설정할 수 있습니다. 182 | 183 | ### 생태계 매개변수 {#ecolib-parameters} 184 | 185 | > 구성 가능한 생태계 매개변수 세트로, 생태계 생성자 계정, 애플리케이션 요소 권한 변경 등의 매개변수를 포함하며, 매개변수 테이블에서 변경할 수 있습니다. 186 | 187 | ### 생태계 구성원 {#ecolib-members} 188 | 189 | > 특정 생태계와 애플리케이션 기능에 액세스할 수 있는 사용자입니다. 190 | 191 | ### 가상 전용 생태계 {#virtual-private-ecolib} 192 | 193 | > Cross Ledgers Base (CLB)라고도 하는 가상 전용 생태계는 표준 생태계의 모든 기능을 갖추고 있지만 블록체인 외부에서 작동합니다. CLB에서는 계약 및 템플릿 언어, 데이터베이스 테이블을 사용하고 Weaver를 사용하여 애플리케이션을 생성할 수 있습니다. 블록체인 생태계의 계약을 인터페이스 방식으로 호출할 수도 있습니다. 194 | 195 | ### 분산화된 권한 증명 {#decentralized-proof-of-authority} 196 | 197 | > 분산화된 권한 증명(DPoA)은 고성능과 용인성을 제공하는 새로운 합의 알고리즘입니다. DPoA에서는 새로운 블록을 생성하는 권한이 이미 그 역할을 증명한 노드에게 부여되며, 이러한 노드는 사전 검증을 거쳐야 합니다. 198 | 199 | ### Needle {#needle} 200 | 201 | > 스마트 계약을 생성하기 위한 스크립트 언어로, 사용자 페이지에서 수신한 데이터 기능을 처리하고 데이터베이스 테이블에서 실행되는 값 조작에 사용될 수 있습니다. 202 | > 203 | > Weaver의 편집기에서 계약을 생성하고 편집할 수 있습니다. 204 | 205 | ### Logicor {#logicor} 206 | 207 | > 페이지를 생성하기 위한 템플릿 언어로, 데이터베이스 테이블에서 값을 가져오고 사용자 페이지를 구축하며 사용자 입력 데이터를 계약의 **data** 부분으로 전달할 수 있습니다. 208 | 209 | ### 통합 개발 환경 (IDE) {#integrated-development-environment-ide} 210 | 211 | > 통합 개발 환경 (Integrated Development Environment, IDE)은 애플리케이션을 생성하기 위한 소프트웨어 도구의 집합입니다. 212 | > 213 | > Weaver의 통합 개발 환경에는 계약 편집기, 페이지 편집기, 데이터베이스 테이블 관리 도구, 다국어 리소스 편집기 및 애플리케이션 내보내기 및 가져오기 기능이 포함되어 있습니다. 통합 개발 환경은 시맨틱 도구 기반의 시각적 페이지 디자이너와 함께 사용됩니다. 214 | 215 | ### 페이지 편집기 {#page-editor} 216 | 217 | > Weaver에서는 기본 애플리케이션 요소인 HTML 컨테이너, 폼 필드, 버튼 등의 도구를 화면에 직접 배치하여 애플리케이션 페이지를 생성할 수 있습니다. 218 | 219 | ### 시각적 페이지 디자이너 {#visual-page-designer} 220 | 221 | > Weaver에서 애플리케이션 페이지를 생성하기 위한 도구로, 인터페이스 디자이너와 Logicor 언어의 페이지 코드 생성기를 포함합니다. 222 | 223 | ### 스마트 계약 편집기 {#contract-editor} 224 | 225 | > Weaver에서 시각적인 페이지를 사용하여 계약을 생성하는 도구입니다. 226 | 227 | ### 다국어 리소스 {#multilingual-resources} 228 | 229 | > Weaver에서 애플리케이션 페이지의 로컬화를 위한 모듈로, 애플리케이션 페이지의 태그를 선택한 언어의 텍스트 값과 연결합니다. 230 | 231 | ### 애플리케이션 내보내기 {#application-export} 232 | 233 | > 애플리케이션의 모든 데이터 테이블, 페이지 및 계약 등의 소스 코드를 파일로 저장합니다. 234 | 235 | ### 애플리케이션 가져오기 {#application-import} 236 | 237 | > 내보낸 파일에 포함된 모든 데이터 테이블, 페이지 및 계약을 에코시스템에 로드합니다. 238 | 239 | ### 스마트 법률 {#smart-law} 240 | 241 | > 규제 정보를 포함하는 특수한 스마트 계약의 집합입니다. 계약의 작업 및 레지스터 액세스 권한을 관리하는 데 사용됩니다. 242 | 243 | ### 법적 체계 {#legal-system} 244 | 245 | > 스마트 법률에서 정의된 규칙 메커니즘으로, 이 규칙은 에코시스템 사용자 간의 관계를 규제하고 프로토콜 매개변수 변경 프로세스 규칙 및 다양한 도전적인 솔루션을 정의합니다. 246 | 247 | ### 애플리케이션 {#application} 248 | 249 | > Weaver의 통합 개발 환경에서 완전한 기능을 갖춘 소프트웨어 제품을 생성합니다. 250 | > 251 | > 응용 프로그램은 구성 액세스 권한을 갖는 데이터베이스 테이블, 스마트 계약 및 사용자 페이지 등의 요소의 집합입니다. 252 | 253 | ### 페이지 {#page} 254 | 255 | > Logicor 템플릿 언어로 작성된 프로그램 코드로 상호 작용 가능한 인터페이스를 화면에 형성합니다. 256 | 257 | ### 코드 조각 {#code-segment} 258 | 259 | > Logicor 템플릿 언어로 작성된 프로그램 코드로, 응용 프로그램 페이지에 반복적으로 포함될 수 있는 코드 블록입니다. 260 | 261 | ### 액세스 권한 {#access-rights} 262 | 263 | > 데이터베이스 테이블, 계약 및 페이지를 생성하고 편집할 수 있는 액세스 권한을 얻는 조건입니다. 264 | > 265 | > 데이터베이스 테이블에 대한 액세스 권한은 행 및 열 추가, 열 값 편집 등의 권한을 설정할 수 있습니다. 266 | 267 | ### 명예 노드 {#honor-node} 268 | 269 | > 블록을 생성하고 검증할 수 있는 네트워크 노드입니다. 270 | 271 | ### 가디언 노드 {#guardian-node} 272 | 273 | > 네트워크에서 전체 블록체인의 최신 버전을 저장하는 노드입니다. 274 | 275 | ### 동시 트랜잭션 처리 {#concurrent-transaction-processing} 276 | 277 | > 서로 다른 생태계에서 데이터를 동시에 처리하여 거래 처리 속도를 향상시키는 방법입니다. 278 | -------------------------------------------------------------------------------- /docs/kr/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # 서버 구성 파일 {#server-configuration-file} 2 | 3 | 이 섹션에서는 서버 구성 파일 매개변수에 대해 설명합니다. 4 | 5 | ## 서버 구성 파일 소개 {#introduction-to-the-server-configuration-file} 6 | 7 | 서버 구성 파일은 IBAX 블록체인 플랫폼 노드의 구성을 정의합니다. 8 | 9 | ## 위치 {#location} 10 | 11 | 이 파일은 서버 작업 디렉토리에 `config.toml`이라는 이름으로 위치합니다. 12 | 13 | ## 섹션 {#sections} 14 | 15 | 구성 파일에는 다음과 같은 섹션이 있습니다. 16 | 17 | > 일반 부분 18 | 19 | 작업 디렉토리 DataDir, 첫 번째 블록 디렉토리 FirstBlockPath 등의 매개변수를 정의합니다. 20 | 21 | > [TCPServer] 22 | 23 | TCP 서버 매개변수를 정의합니다. 24 | 25 | TCPServer는 노드 간의 네트워크 상호작용에 사용됩니다. 26 | 27 | > [HTTP] 28 | 29 | HTTP 서버 매개변수를 정의합니다. 30 | 31 | HTTPServer는 RESTful API를 제공합니다. 32 | 33 | > [DB] 34 | 35 | PostgreSQL 노드 데이터베이스 매개변수를 정의합니다. 36 | 37 | > [StatsD] 38 | 39 | 작업 지표 수집기인 StatsD의 매개변수를 정의합니다. 40 | 41 | > [Centrifugo] 42 | 43 | 알림 서비스 Centrifugo의 매개변수를 정의합니다. 44 | 45 | > [Log] 46 | 47 | 로그 서비스 Log의 매개변수를 정의합니다. 48 | 49 | > [TokenMovement] 50 | 51 | 토큰 이동 서비스 TokenMovement의 매개변수를 정의합니다. 52 | 53 | ## 설정 파일 예시 {#an-example-configuration-file} 54 | 55 | ``` js 56 | PidFilePath = "/ibax-data/go-ibax.pid" 57 | LockFilePath = "/ibax-data/go-ibax.lock" 58 | DataDir = "/ibax-data" 59 | KeysDir = "/ibax-data" 60 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/ibax-temp" 61 | FirstBlockPath = "/ibax-data/1block" 62 | TLS = false 63 | TLSCert = "" 64 | TLSKey = "" 65 | OBSMode = "none" 66 | HTTPServerMaxBodySize = 1048576 67 | MaxPageGenerationTime = 3000 68 | NodesAddr = [] 69 | 70 | [TCPServer] 71 | Host = "127.0.0.1" 72 | Port = 7078 73 | 74 | [HTTP] 75 | Host = "127.0.0.1" 76 | Port = 7079 77 | 78 | [DB] 79 | Name = "ibax" 80 | Host = "127.0.0.1" 81 | Port = 5432 82 | User = "postgres" 83 | Password = "123456" 84 | LockTimeout = 5000 85 | 86 | [StatsD] 87 | Host = "127.0.0.1" 88 | Port = 8125 89 | Name = "ibax" 90 | 91 | [Centrifugo] 92 | Secret = "127.0.0.1" 93 | URL = "127.0.0.1" 94 | 95 | [Log] 96 | LogTo = "stdout" 97 | LogLevel = "ERROR" 98 | LogFormat = "text" 99 | [Log.Syslog] 100 | Facility = "kern" 101 | Tag = "go-ibax" 102 | 103 | [TokenMovement] 104 | Host = "" 105 | Port = 0 106 | Username = "" 107 | Password = "" 108 | To = "" 109 | From = "" 110 | Subject = "" 111 | ``` 112 | -------------------------------------------------------------------------------- /docs/kr/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # 실시간 모니터링 도구 {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor는 지정된 노드의 데이터베이스가 동기화되었는지 확인하는 특수 도구입니다. 4 | 5 | 이 도구는 데몬으로 사용하거나 일회성 검사를 실행하는 데 사용할 수 있습니다. 6 | 7 | 이 도구의 작동 원리는 다음과 같습니다: 8 | 9 | > 1. 각 블록에는 모든 거래의 변경 내용에 대한 해시가 포함되어 있으며, 지정된 노드에 마지막 블록 ID를 요청합니다. 10 | > 2. 그런 다음 해당 ID를 가진 블록을 모든 노드에서 요청하고 위의 해시를 비교합니다. 11 | > 3. 해시가 다른 경우, 동기화 오류 메시지가 지정된 이메일 주소로 전송됩니다. 12 | 13 | ## 위치 {#location} 14 | 15 | 이 도구는 `tools/desync_monitor/`에 위치해 있습니다. 16 | 17 | ## 명령 프롬프트 플래그 {#command-prompt-flags} 18 | 19 | 다음 플래그를 사용하여 명령 프롬프트에서 사용할 수 있습니다: 20 | 21 | > - **confPath** -- 구성 파일의 경로입니다. 기본 파일 이름은 `config.toml`입니다. 22 | > - **nodesList** -- 블록을 요청할 노드 목록입니다. 쉼표로 구분됩니다. 기본값은 `127.0.0.1:7079`입니다. 23 | > - **daemonMode** -- 데몬 모드로 실행하여 N초마다 확인해야 할 경우 사용합니다. 이 플래그는 기본적으로 `false`로 설정됩니다. 24 | > - **queryingPeriod** -- 도구를 데몬 모드로 실행할 경우, 확인 간의 시간 간격(초)을 설정합니다. 기본값은 `1`초입니다. 25 | 26 | - **alertMessageTo** -- 동기화 경고 오류를 받을 이메일 주소입니다. 27 | 28 | > - **alertMessageSubj** -- 경고 메시지의 제목입니다. 기본값은 "노드 동기화 문제"입니다. 29 | > - **alertMessageFrom** -- 메시지를 보내는 주소입니다. 30 | > - **smtpHost** -- 이메일을 보내기 위한 SMTP 서버 호스트입니다. 기본값은 `""`입니다. 31 | > - **smtpPort** -- 이메일 메시지를 보내기 위한 SMTP 서버 포트입니다. 기본값은 `25`입니다. 32 | > - **smtpUsername** -- SMTP 서버 사용자 이름입니다. 기본값은 `""`입니다. 33 | > - **smtpPassword** -- SMTP 서버 비밀번호입니다. 기본값은 `""`입니다. 34 | 35 | ## 구성 {#configuration} 36 | 37 | 이 도구는 toml 형식의 구성 파일을 사용합니다. 38 | 39 | 기본적으로 실행 파일이 있는 폴더에서 *config.toml* 파일을 찾습니다. 40 | 41 | **configPath** 플래그를 사용하여 파일 경로를 변경할 수 있습니다. 42 | 43 | ```text 44 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 45 | 46 | [daemon] 47 | daemon = false 48 | querying_period = 1 49 | 50 | [alert_message] 51 | to = "" 52 | subject = "problem with xxx nodes" 53 | from = "" 54 | 55 | [smtp] 56 | host = "" 57 | port = 25 58 | username = "" 59 | password = "" 60 | ``` 61 | 62 | ### nodes_list {#nodes-list} 63 | 64 | > - **nodes_list** -- 요청 정보의 노드(호스트) 목록을 요청합니다. 65 | 66 | ### [daemon] {#daemon} 67 | 68 | 데몬 모드 구성. 69 | 70 | > - **daemon_mode** -- 도구가 데몬으로 작동하고 동기화 검사를 수행합니다. 71 | > - **querying_period** -- 동기화 검사 간의 시간 간격. 72 | 73 | ### [alert_message] {#alert-message} 74 | 75 | 경고 메시지 매개변수. 76 | 77 | > - **to** -- 동기화 오류 경고 메시지를 받을 수신자 주소; 78 | > - **subject** -- 메시지 주제; 79 | > - **from** -- 발신자 주소. 80 | 81 | ### [smtp] {#smtp} 82 | 83 | 동기화 오류 메시지를 보내기 위한 (Simple Mail Transfer Protocol SMTP) 서버 매개변수. 84 | 85 | > - **host** -- SMTP 서버 호스트; 86 | > - **port** -- SMTP 서버 포트; 87 | > - **username** -- SMTP 서버 사용자 이름; 88 | > - **password** -- SMTP 서버 비밀번호; 89 | -------------------------------------------------------------------------------- /docs/kr/topics/daemons.md: -------------------------------------------------------------------------------- 1 | 2 | # 데몬 {#daemon} 3 | 4 | 이 섹션에서는 기술적인 관점에서 IBax 노드가 서로 상호 작용하는 방법에 대해 설명합니다. 5 | 6 | ## 서버 데몬에 대하여 {#about-the-server-daemon} 7 | 8 | 서버 데몬은 모든 네트워크 노드에서 실행되어 다양한 서버 기능을 수행하고 IBax의 블록체인 프로토콜을 지원해야 합니다. 블록체인 네트워크에서 데몬은 블록과 거래를 분배하고, 새로운 블록을 생성하며, 받은 블록과 거래를 검증하고, 포크 이슈를 방지할 수 있습니다. 9 | 10 | ### 영광 노드 데몬 {#honor-node-daemon} 11 | 12 | 영광 노드는 다음과 같은 서버 데몬을 실행합니다: 13 | 14 | * [BlockGenerator daemon](#blockgenerator-daemon) 15 | 16 | 새로운 블록 생성 17 | 18 | * [BlockCollection daemon](#blockcollection-daemon) 19 | 20 | 다른 노드에서 새로운 블록 다운로드 21 | 22 | * [Confirmations daemon](#confirmations-daemon) 23 | 24 | 해당 노드의 블록이 대부분의 다른 노드에도 존재하는지 확인 25 | 26 | * [Disseminator daemon](#disseminator-daemon) 27 | 28 | 거래와 블록을 다른 영광 노드로 배포 29 | 30 | * QueueParserBlocks daemon 31 | 32 | 큐에 있는 블록, 다른 노드에서 가져온 블록이 포함됨 33 | 34 | 블록 처리 로직은 [BlockCollection daemon](#blockcollection-daemon)과 동일 35 | 36 | * QueueParserTx daemon 37 | 38 | 큐에 있는 거래 검증 39 | 40 | * Scheduler daemon 41 | 42 | 계약을 예약된 시간에 실행 43 | 44 | 45 | ### 수호자 노드 데몬 (Guardian Node Daemon) {#guardian-node-daemon} 46 | 47 | 수호자 노드는 다음과 같은 서버 데몬을 실행합니다: 48 | 49 | * [BlockCollection daemon](#blockcollection-daemon) 50 | * [Confirmations daemon](#confirmations-daemon) 51 | * [Disseminator daemon](#disseminator-daemon) 52 | * QueueParserTx 53 | * Scheduler 54 | 55 | ## 블록 수집 데몬 (BlockCollection Daemon) {#blockcollection-daemon} 56 | 57 | 이 데몬은 블록을 다운로드하고 블록체인을 다른 네트워크 노드와 동기화합니다. 58 | 59 | ### 블록체인 동기화 {#blockchain-synchronization} 60 | 61 | 이 데몬은 블록체인 네트워크에서 최대 블록 높이를 결정하고, 새로운 블록을 요청하며, 블록체인에서 포크 이슈를 해결함으로써 블록체인을 동기화합니다. 62 | 63 | #### 블록체인 업데이트 확인 {#check-for-blockchain-updates} 64 | 65 | 이 데몬은 현재 블록 ID부터 모든 영광 노드에게 요청을 보냅니다. 66 | 67 | 데몬을 실행 중인 노드의 현재 블록 ID가 어떤 영광 노드의 현재 블록 ID보다 작다면, 해당 블록체인 네트워크 노드는 오래된 것으로 간주됩니다. 68 | 69 | #### 새 블록 다운로드 {#download-new-blocks} 70 | 71 | 가장 큰 현재 블록 높이를 반환하는 노드가 최신 노드로 간주됩니다. 72 | 데몬은 모든 알 수 없는 블록을 다운로드합니다. 73 | 74 | #### 포크 문제 해결 {#solving-the-fork-issue} 75 | 76 | 블록체인에서 포크가 감지되면 데몬은 모든 블록을 공통 상위 블록으로 다운로드하여 포크를 뒤로 이동합니다. 77 | 공통 상위 블록이 발견되면 데몬을 실행하는 노드에서 블록체인 롤백이 수행되고 최신 블록이 포함될 때까지 올바른 블록이 블록체인에 추가됩니다. 78 | 79 | ### Tables {#tables-1} 80 | 81 | BlocksCollection 데몬은 다음 테이블을 사용합니다. 82 | 83 | * block_chain 84 | * transactions 85 | * transactions_status 86 | * info_block 87 | 88 | ### Request {#request-1} 89 | 90 | BlockCollection 데몬은 다음 요청을 다른 데몬으로 보냅니다. 91 | 92 | * [Type 10](#type-10) 은 전체 명예 노드 중 가장 큰 블록 ID를 가리킵니다. 93 | * [Type 7](#type-7) 은 블록 ID가 가장 큰 데이터를 가리킵니다. 94 | 95 | ## BlockGenerator 데몬 {#blockgenerator-daemon} 96 | 97 | BlockGenerator 데몬은 새 블록을 생성합니다. 98 | 99 | ### 사전 검증 {#pre-verification} 100 | 101 | BlockGenerator 데몬은 블록체인의 최신 블록을 분석하여 새로운 블록 생성 계획을 세웁니다. 102 | 103 | 다음 조건이 충족되면 새 블록을 생성할 수 있습니다. 104 | 105 | * 최신 블록을 생성한 노드는 Honor Node 목록 내의 노드에 있으며 데몬을 실행합니다. 106 | * 가장 최근에 검증되지 않은 블록이 생성된 이후 가장 짧은 시간입니다. 107 | 108 | ### 블록 생성 {#block-generation} 109 | 110 | 데몬에 의해 생성된 새로운 블록에는 다른 노드의 [Disseminator 데몬](#disseminator-daemon)에서 받거나 데몬을 실행하는 노드에서 생성할 수 있는 모든 새 트랜잭션이 포함됩니다. 생성된 블록은 노드 데이터베이스에 저장됩니다. 111 | 112 | ### Tables {#tables-2} 113 | 114 | BlockGenerator 데몬은 다음 테이블을 사용합니다. 115 | 116 | * block_chain (saves new blocks) 117 | * transactions 118 | * transactions_status 119 | * info_block 120 | 121 | ### Request {#request-2} 122 | 123 | BlockGenerator 데몬은 다른 데몬에 요청하지 않습니다. 124 | 125 | ## 디세미네이터 데몬 {#disseminator-daemon} 126 | 127 | Disseminator 데몬은 트랜잭션과 블록을 모든 명예 노드로 보냅니다. 128 | 129 | ### 가디언 노드 {#guardian-node} 130 | 131 | 가디언 노드에서 작업할 때 데몬은 해당 노드에서 생성된 트랜잭션을 모든 명예 노드로 보냅니다. 132 | 133 | ### 명예노드 {#honor-node} 134 | 135 | 명예 노드에서 작업할 때 데몬은 생성된 블록과 트랜잭션 해시를 모든 명예 노드로 보냅니다. 136 | 137 | 그런 다음 Honor Node는 자신에게 알려지지 않은 트랜잭션 요청에 응답합니다. 데몬은 전체 트랜잭션 데이터를 응답으로 보냅니다. 138 | 139 | ### Tables {#tables-3} 140 | 141 | Disseminator 데몬은 다음 테이블을 사용합니다. 142 | 143 | * transactions 144 | 145 | ### Request {#request-3} 146 | 147 | Disseminator 데몬은 다음 요청을 다른 데몬으로 보냅니다. 148 | 149 | * [Type 1](#type-1) 트랜잭션 및 블록 해시를 Honor 노드로 보냅니다. 150 | * [Type 2](#type-2) 아너노드로부터 트랜잭션 데이터를 받습니다. 151 | 152 | ## 확인 데몬 {#confirmations-daemon} 153 | 154 | 확인 데몬은 노드의 모든 블록이 대부분의 다른 노드에 있는지 확인합니다. 155 | 156 | ### 차단 확인 {#block-confirmation} 157 | 158 | 네트워크의 여러 노드에서 확인한 블록은 확인된 블록으로 간주됩니다. 159 | 160 | 데몬은 현재 데이터베이스에서 확인되지 않은 첫 번째 블록부터 하나씩 모든 블록을 확인합니다. 161 | 162 | 각 블록은 다음과 같은 방식으로 확인됩니다. 163 | 164 | * 확인 중인 블록의 ID가 포함된 요청을 모든 명예 노드에 보냅니다. 165 | * 모든 명예 노드는 블록 해시에 응답합니다. 166 | * 응답한 해시가 데몬 노드에 있는 블록의 해시와 일치하면 확인 카운터 값이 증가합니다. 그렇지 않은 경우 취소 카운터 값이 증가합니다. 167 | 168 | ### Tables {#tables-4} 169 | 170 | 확인 데몬은 다음 테이블을 사용합니다. 171 | 172 | * confirmation 173 | * info_block 174 | 175 | ### Request {#request-4} 176 | 177 | 확인 데몬은 다음 요청을 다른 데몬으로 보냅니다. 178 | 179 | * [Type 4](#type-4) 명예 노드에서 블록 해시를 요청합니다. 180 | 181 | ## TCP 서비스 프로토콜 {#tcp-service-protocol} 182 | 183 | TCP 서비스 프로토콜은 명예 노드 및 가디언 노드에서 작동하며 TCP의 이진 프로토콜을 사용하여 BlocksCollection, Disseminator 및 Confirmation 데몬의 요청에 사용합니다. 184 | 185 | ## 요청 유형 {#request-type} 186 | 187 | 각 요청에는 요청의 처음 두 바이트로 정의된 유형이 있습니다. 188 | 189 | ## 유형 1 {#type-1} 190 | 191 | #### 발신자 요청 {#request-sender-1} 192 | 193 | 이 요청은 [Disseminator 데몬](#disseminator-daemon)에 의해 전송됩니다. 194 | 195 | #### 데이터 요청 {#request-data-1} 196 | 197 | 트랜잭션 및 블록의 해시. 198 | 199 | #### 요청 처리 {#request-processing-1} 200 | 201 | 블록 해시가 블록 대기열에 추가됩니다. 202 | 203 | 트랜잭션 해시를 분석 및 검증하고 아직 노드에 나타나지 않은 트랜잭션을 선택합니다. 204 | 205 | #### 응답 {#response-1} 206 | 207 | 아니요. 요청을 처리한 후 [Type 2](#type-2) 요청이 발행됩니다. 208 | 209 | ## 유형 2 {#type-2} 210 | 211 | #### 발신자 요청 {#request-sender-2} 212 | 213 | 이 요청은 [Disseminator 데몬](#disseminator-daemon)에 의해 전송됩니다. 214 | 215 | #### 데이터 요청 {#request-data-2} 216 | 217 | 데이터 크기를 포함한 트랜잭션 데이터: 218 | 219 | * data_size(4바이트) 220 | 221 | * 트랜잭션 데이터의 크기(바이트). 222 | 223 | * 데이터(data_size 바이트) 224 | 225 | 거래 데이터입니다. 226 | 227 | #### 요청 처리 {#request-processing-2} 228 | 229 | 트랜잭션을 확인하고 트랜잭션 대기열에 추가합니다. 230 | 231 | #### 응답 {#response-2} 232 | 233 | 아니요. 234 | 235 | ## 유형 4 {#type-4} 236 | 237 | #### 발신자 요청 {#request-sender-3} 238 | 239 | 이 요청은 [확인 데몬](#confirmations-daemon)에서 보냅니다. 240 | 241 | #### 데이터 요청 {#request-data-3} 242 | 243 | 블록 ID. 244 | 245 | #### 응답 {#response-3} 246 | 247 | 블록 해시. 248 | 249 | 이 ID를 가진 블록이 없으면 `0` 을 반환합니다. 250 | 251 | ## 유형 7 {#type-7} 252 | 253 | #### 발신자 요청 {#request-sender-4} 254 | 255 | 이 요청은 [BlockCollection 데몬](#blockcollection-daemon)에서 보냅니다. 256 | 257 | #### 데이터 요청 {#request-data-4} 258 | 259 | 블록 ID. 260 | 261 | * block_id(4바이트) 262 | 263 | #### 응답 {#response-4} 264 | 265 | 데이터 크기를 포함한 블록 데이터. 266 | 267 | * data_size(4바이트) 268 | 269 | * 블록 데이터의 크기(바이트). 270 | 271 | * 데이터(data_size 바이트) 272 | 273 | 블록 데이터. 274 | 275 | 이 ID를 가진 블록이 없으면 연결이 닫힙니다. 276 | 277 | ## 유형 10 {#type-10} 278 | 279 | #### 발신자 요청 {#request-sender-5} 280 | 281 | 이 요청은 [BlockCollection 데몬](#blockcollection-daemon)에서 보냅니다. 282 | 283 | #### 데이터 요청 {#request-data-5} 284 | 285 | 아니요. 286 | 287 | #### 응답 {#response-5} 288 | 289 | 블록 ID. 290 | 291 | * block_id (4바이트) 292 | 293 | -------------------------------------------------------------------------------- /docs/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # Server Configuration File {#server-configuration-file} 2 | 3 | In this section, we will introduce parameters in the server configuration file. 4 | 5 | ## Introduction to the server configuration file {#introduction-to-the-server-configuration-file} 6 | 7 | The server configuration file defines the node configuration of IBAX. 8 | 9 | ## Location {#location} 10 | 11 | This file is located in the working directory of the server and is named `config.toml`. 12 | 13 | ## Sections {#sections} 14 | 15 | The configuration file consists the following sections: 16 | 17 | > general section 18 | 19 | It defines the working directory DataDir, the first block directory FirstBlockPath and other parameters. 20 | 21 | > [TCPServer] 22 | 23 | It defines the TCP service parameters. 24 | 25 | TCPServer is used for the network interaction between nodes. 26 | 27 | > [HTTP] 28 | 29 | It defines the HTTP service parameters. 30 | 31 | HTTPServer provides RESTful APIs. 32 | 33 | > [DB] 34 | 35 | It defines parameters of the PostgreSQL node database. 36 | 37 | > [StatsD] 38 | 39 | It defines parameters of the node operation indicator collector StatsD. 40 | 41 | > [Centrifugo] 42 | 43 | It defines parameters of the notification service Centrifugo. 44 | 45 | > [Log] 46 | 47 | It defines parameters of the log service Log. 48 | 49 | > [TokenMovement] 50 | 51 | It defines parameters of the token circulation service TokenMovement. 52 | 53 | ## An example configuration file {#an-example-configuration-file} 54 | 55 | ``` js 56 | PidFilePath = "/ibax-data/go-ibax.pid" 57 | LockFilePath = "/ibax-data/go-ibax.lock" 58 | DataDir = "/ibax-data" 59 | KeysDir = "/ibax-data" 60 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/ibax-temp" 61 | FirstBlockPath = "/ibax-data/1block" 62 | TLS = false 63 | TLSCert = "" 64 | TLSKey = "" 65 | OBSMode = "none" 66 | HTTPServerMaxBodySize = 1048576 67 | MaxPageGenerationTime = 3000 68 | NodesAddr = [] 69 | 70 | [TCPServer] 71 | Host = "127.0.0.1" 72 | Port = 7078 73 | 74 | [HTTP] 75 | Host = "127.0.0.1" 76 | Port = 7079 77 | 78 | [DB] 79 | Name = "ibax" 80 | Host = "127.0.0.1" 81 | Port = 5432 82 | User = "postgres" 83 | Password = "123456" 84 | LockTimeout = 5000 85 | 86 | [StatsD] 87 | Host = "127.0.0.1" 88 | Port = 8125 89 | Name = "ibax" 90 | 91 | [Centrifugo] 92 | Secret = "127.0.0.1" 93 | URL = "127.0.0.1" 94 | 95 | [Log] 96 | LogTo = "stdout" 97 | LogLevel = "ERROR" 98 | LogFormat = "text" 99 | [Log.Syslog] 100 | Facility = "kern" 101 | Tag = "go-ibax" 102 | 103 | [TokenMovement] 104 | Host = "" 105 | Port = 0 106 | Username = "" 107 | Password = "" 108 | To = "" 109 | From = "" 110 | Subject = "" 111 | ``` 112 | -------------------------------------------------------------------------------- /docs/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # Synchronized Monitoring Tool {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor is a special tool that can be used to verify whether the database on the specified node has been synchronized. 4 | 5 | The tool can be used as a daemon or can be started to perform a one-time check. 6 | 7 | The operating principle of the tool is based on the following: 8 | 9 | 1. Each block contains the hash of all changes of all transactions, request the specified node to provide its last block ID; 10 | 2. Then request a block with this ID from all nodes and compare the above hashes; 11 | 3. If the hashes are different, a synchronization error message will be sent to the email address specified in the command. 12 | 13 | ## Location {#location} 14 | 15 | The tool is located in the `tools/desync_monitor/` directory. 16 | 17 | ## Command prompt flags {#command-prompt-flags} 18 | 19 | The following flags can be used from the command prompt: 20 | 21 | > - **confPath** -- Path of the configuration file. The default file name is `config.toml`; 22 | > - **nodesList** -- Node list of the requested block, separated by commas. The default is `127.0.0.1:7079`; 23 | > - **daemonMode** -- Started as a daemon and should be used when authentication is required every N seconds. This flag is set to `false` by default; 24 | > - **queryingPeriod** -- If the tool is started as a daemon, this parameter sets the time interval (in seconds) between checks, `1` second by default. 25 | 26 | - **alertMessageTo** -- The email address to which synchronization warning errors will be sent. 27 | 28 | > - **alertMessageSubj** -- Message subject in the warning message, the `node synchronization` problem by default; 29 | > - **alertMessageFrom** -- Address where the message was sent. 30 | > - **smtpHost** -- SMTP server host, used to send emails, the `""` by default; 31 | > - **smtpPort** -- SMTP server port, used to send email messages, `25` by default; 32 | > - **smtpUsername** -- SMTP server username, `""` by default; 33 | > - **smtpPassword** -- SMTP server password, `""` by default. 34 | 35 | ## Configuration {#configuration} 36 | 37 | The tool uses a configuration file in toml format. 38 | 39 | By default, it will look for the config.toml file in the folder where to start up the binary file. 40 | 41 | The file path can be changed with the **configPath**. 42 | 43 | ```text 44 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 45 | 46 | [daemon] 47 | daemon = false 48 | querying_period = 1 49 | 50 | [alert_message] 51 | to = "" 52 | subject = "problem with xxx nodes" 53 | from = "" 54 | 55 | [smtp] 56 | host = "" 57 | port = 25 58 | username = "" 59 | password = "" 60 | ``` 61 | 62 | ### nodes_list {#nodes-list} 63 | 64 | * nodes_list - List of nodes (hosts) requesting information. 65 | 66 | ### [daemon] {#daemon} 67 | 68 | Configuration of the daemon mode. 69 | 70 | > - **daemon_mode** -- A tool works as a daemon and performs synchronization checks. 71 | > - **querying_period** -- Time interval between synchronization checks. 72 | 73 | ### [alert_message] {#alert-message} 74 | 75 | Warning message parameters. 76 | 77 | > - **to** -- recipient's e-mail of synchronization error warning messages; 78 | > - **subject** -- message subject; 79 | > - **from** -- sender's e-mail. 80 | 81 | ### [smtp] {#smtp} 82 | 83 | Simple Mail Transfer Protocol (SMTP) server parameters, used to send synchronization error messages. 84 | 85 | > - **host** -- SMTP server hose; 86 | > - **port** -- SMTP server port; 87 | > - **username** -- SMTP server user name; 88 | > - **password** --SMTP server password; 89 | -------------------------------------------------------------------------------- /docs/tr-TR/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: Merkezi olmayan bir ticari zincirler arası altyapı ağı 6 | actionText: Hızlı başlangıç → 7 | actionLink: /tr-TR/concepts/about-the-platform.html 8 | features: 9 | - title: Blockchain uygulama maliyetlerinde büyük bir azalma 10 | - title: Bağımsız olarak oluşturulmuş bir fiziksel ekosistem 11 | - title: Dağıtılmış sunucuların, geliştirme ve uygulama ortamlarının hızlı dağıtımı 12 | - title: Çeşitlendirilmiş bir DApp mağazası ve BaaS işlevselliği 13 | - title: Saniyeler içinde gerçek hizmet yanıtı 14 | - title: Chainler arası ve sistemler arası veri etkileşimi 15 | - title: Kamu, ittifak ve özel chainleri entegre eden yeni bir altyapı ağı 16 | - title: Özelleştirilebilir bir fikir birliği mekanizması 17 | - title: Farklı şifreleme ihtiyaçlarını karşılamak için front-end ve back-end ayrımı 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 06/20/2023 | Built with VuePress 20 | --- 21 | 22 | 23 | # IBAX Dokümantasyon 24 | 25 | 26 | ## Konsept 27 | 28 | * [IBAX Genel Bakış](concepts/about-the-platform.md) 29 | * [The IBAX Network](concepts/blockchain-layers.md) 30 | * [Proof-of-Authority Konsensüs](concepts/consensus.md) 31 | * [Terimler ve tanımlar](concepts/thesaurus.md) 32 | * [SSS](concepts/faq.md) 33 | 34 | ## Öğretici 35 | 36 | * [Uygulama geliştirme eğitimi](tutorials/app_tutorial.md) 37 | * [Development Tutorial](tutorials/tutorial.md) 38 | 39 | ## Kılavuz 40 | 41 | * [Akıllı Kontratlar](topics/script.md) 42 | * [Şablon Dili](topics/templates2.md) 43 | * [Derleyici ve Sanal Makine](topics/vm.md) 44 | * [Daemon](topics/daemons.md) 45 | 46 | ## Referans 47 | 48 | * [RESTful API](reference/api2.md) 49 | * [Platform Parametreleri](reference/platform-parameters.md) 50 | * [Sunucu yapılandırma dosyası](reference/backend-config.md) 51 | * [Senkronize İzleme Aracı](reference/desync_monitor.md) 52 | * [JSON-RPC Application Programming Interface](reference/json-rpc.md) 53 | 54 | ## Dağıtım 55 | 56 | * [Bir IBAX Ağının Kurulması](howtos/deployment.md) 57 | 58 | -------------------------------------------------------------------------------- /docs/tr-TR/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # The IBAX Network {#the-ibax-network} 2 | 3 | Bu bölümde size IBAX'ın nasıl kullanılacağını anlatacağız. 4 | 5 | - [The IBAX Network](#the-ibax-network) 6 | - [Uygulama geliştiricileri](#application-developers) 7 | - [ECOLIB üyeleri](#ecolib-members) 8 | - [ECOLIB uygulamalar ve platform uygulamaları](#ecolib-applications-and-platform-applications) 9 | - [Temel model](#underlying-model) 10 | - [Uygulama](#implementation) 11 | 12 | 13 | 14 | 15 | 16 | 17 | IBAX'teki uygulamaların geliştirilmesi, kullanımı veya yönetimi ile ilgileniyorsanız, bunu hiç anlamanız gerekmeyebilir. 18 | 19 | IBAX'te blok zinciri ve blok zinciri ağı, ECOLIB üyelerinden, yöneticilerinden ve uygulama geliştiricilerinden gizlenmiştir. IBAX, tüm kullanıcı grupları için blok zincirinin **küresel durumuna** kurcalanmaya karşı korumalı ve dağıtılmış erişim sağlayan [RESTful API](../reference/api2.md) sunar. 20 | 21 | ## Uygulama geliştiricileri {#application-developers} 22 | 23 | Teknik terimlerle, **küresel durum**, IBAX'ın veri tabanı aracılığıyla uygulanan bir dizi veridir. Uygulama geliştiricilerin bakış açısından, bir uygulama tabloları sorgulayarak, ekleyerek ve güncelleyerek veritabanı ile etkileşime girer. 24 | 25 | IBAX'te işlemler, çeşitli sözleşmeler uygulanarak blok zincirine yazılır. Bu işlemler, küresel durumu (veritabanı) buna göre güncelleyecek olan blok zinciri ağ düğümleri tarafından uygulanan sözleşme kodlarını arayacaktır. 26 | 27 | Uygulama geliştiricileri için sözleşme, uygulandığında verilerin veritabanına yazılacağı bir işlevdir. Sayfalar komut dosyaları gibidir ve sayfa kodu bir dizi sayfa [şablon](../topics/templates2.md) işlevidir, bu işlevlerden bazıları sayfa öğelerini görüntülerken, diğer veriler veritabanından gelir. Uygulama geliştiricilerin işlemlerin, blok oluşturma ve konsensüs algoritmalarının ne olduğunu anlamalarına gerek yok, sadece kullanın. 28 | 29 | ## ECOLIB üyeleri {#ecolib-members} 30 | 31 | Geliştiriciler tarafından yazılan uygulamalar, [ECOLIB](thesaurus.md#ecolib) adlı bir ortamda çalışır. Bir uygulama genellikle belirli bir amaca hizmet eder ve diğer birkaç uygulamayla birlikte çeşitli görevleri tamamlar. 32 | 33 | Bir kullanıcı, içindeki uygulamalara erişmek istiyorsa bir ECOLIB'ye üye olmalıdır ve aynı anda birden fazla farklı ECOLIB'ye üye olabilir. 34 | 35 | ECOLIB üyeleri, ortak bir web uygulamasındaki formları doldurmak, düğmelere tıklamak ve sayfalarda gezinmek gibi, uygulama sayfalarından veri tabanını görüntüleyebilir ve değiştirebilir. 36 | 37 | ## ECOLIB uygulamaları ve platform uygulamaları {#ecolib-applications-and-platform-applications} 38 | 39 | Başvurular **ECOLIB uygulamaları** ve **platform uygulamaları** olarak ayrılabilir. 40 | 41 | ECOLIB uygulamaları 42 | 43 | Bir ECOLIB uygulaması, bir ECOLIB'nin belirli benzersiz işlevlerini veya iş süreçlerini uygular, ancak yalnızca o ECOLIB'de mevcuttur. 44 | Platform uygulamaları 45 | 46 | Tüm ECOLIB'ler için bir platform uygulaması geçerlidir. Herhangi bir uygulama bir platform uygulaması olarak geliştirilebilir. IBAX geliştiricileri, oylama, bildirim ve ECOLIB üye rol yönetimi gibi ECOLIB yönetişimi için temel işlevleri destekleyen platform uygulamaları sağlayacaktır. 47 | 48 | ## Temel model {#underlying-model} 49 | 50 | katmanların tanımı 51 | 52 | IBAX birkaç katmandan oluşur: 53 | 54 | * Kullanıcı etkileşimi katmanı 55 | 56 | ECOLIB üyeleri, sayfalar ve sayfa öğeleri aracılığıyla uygulama ile etkileşime girer. 57 | 58 | * Uygulama katmanı 59 | 60 | Uygulama geliştiricileri, sözleşme kodları ve sayfa kodları aracılığıyla küresel durumla (veri tabloları) etkileşime girer. 61 | 62 | * Küresel durum katmanı 63 | 64 | Dağıtılmış deftere (blockchain) yazılan işlemlere dayalı olarak küresel durumu (veritabanı) güncelleyin ve senkronize edin 65 | * Blok zinciri katmanı 66 | 67 | Dağıtılmış defteri yeni bloklarla güncelleyin. Yeni bloklarda kaydedilen işlemler (işlemler) global durumda gerçekleştirilmelidir. 68 | 69 | * Düğüm ağ katmanı 70 | 71 | Düğüm ağında işlemleri dağıtan, doğrulayan ve yeni bloklar oluşturan IBAX Ağı protokolünü uyguladı. Benzer şekilde, yeni bloklar düğüm ağı tarafından dağıtılır ve doğrulanır. 72 | 73 | Tüm düğümlerin dağıtılmış defteri senkronize tutulur. Bir düğümde çakışmalar varsa, düğüm hangi blok zincirlerinin geçerli kabul edildiğini belirleyecek ve geçersiz blok zincirleri buna göre geri alınacaktır. 74 | 75 | * İşlem katmanı 76 | 77 | İşlemler, blokların ve blok zinciri protokollerinin oluşturulmasının temelidir ve işlemlerin kendisi, kullanıcı etkileşimi katmanında gerçekleştirilen işlemlerin sonuçlarıdır. İşlemler Weaver tarafından oluşturulur. 78 | 79 | Bir kullanıcı veya geliştirici, bir sayfadaki bir düğmeyi tıklamak veya kod düzenleyiciden bir sözleşme uygulamak gibi bir işlem gerçekleştirdiğinde, Weaver bu işlemi bir işleme dönüştürecek ve kendisine bağlı ağ düğümüne gönderecektir. 80 | 81 | Bu nedenle, işlem akışı aşağıdaki gibidir: 82 | 83 | * Bir kullanıcı sayfasındaki bir kullanıcı işlemi, bir işleme dönüşecektir; 84 | * İşlem bir blokta bulunur; 85 | 86 | * Blok, blok zincirine dahildir; 87 | 88 | * İşlem değişikliği, blok zincirinin küresel durumunun değişmesine neden olacak ve bu işlem veritabanına uygulanacaktır; 89 | 90 | * Herhangi bir veritabanı değişikliği uygulamaya yansıtılacaktır. 91 | 92 | ## Uygulama {#implementation} 93 | 94 | IBAX'in iki ana bileşeni vardır, yani sunucu [go-ibax](https://github.com/IBAX-io/go-ibax) ve Weaver [Kaynak kodu](https://github.com/IBAX-io/weaver ). 95 | 96 | dokumacı: 97 | * Kullanıcı sayfalarının sağlanması; 98 | * Uygulama geliştirme için IDE sağlanması; 99 | * Kullanıcı hesaplarının açık anahtarlarının saklanması ve yetkilendirme yapılması; 100 | * Uygulama sayfalarından veri tabanı verilerini talep etme ve uygulama sayfalarını kullanıcılara gösterme; 101 | * İşlemleri [REST API'leri](../reference/api2.md) üzerinden sunucuya gönderme; 102 | 103 | Kullanıcı işlemlerine karşı otomatik olarak işlemler oluşturmak için, uygulama geliştiricileri IDE'den bir sözleşme uyguladığında Weaver bu işlemleri işlemlere dönüştürecektir. 104 | 105 | sunucu: 106 | * Düğümün global durumunu (veritabanı) tutmak; 107 | * Blok zinciri protokolünün uygulanması; 108 | * IBAX [Sanal Makinede](../topics/vm.md) sözleşme kodlarının uygulanması; 109 | * [Şablon Motorunda](../topics/templates2.md) sayfa kodlarının uygulanması; 110 | * [RESTful API](../reference/api2.md) uygulaması. -------------------------------------------------------------------------------- /docs/tr-TR/concepts/consensus.md: -------------------------------------------------------------------------------- 1 | 2 | # Decentralized Proof-of-Authority Consensus {#decentralized-proof-of-authority-consensus} 3 | 4 | * Merkezi Olmayan Yetki Kanıtı fikir birliği nedir 5 | 6 | * DPoA konsensüsünün avantajları 7 | 8 | * DPoA konsensüsü ve ortak saldırı araçları 9 | 10 | * IBAX'te DPoA konsensüsünün uygulanması 11 | 12 | Bu bölümde, Merkezi Olmayan Yetki Kanıtı fikir birliğini ve bunun IBAX'teki uygulamasını açıklayacağız. 13 | 14 | 15 | - [Decentralized Proof-of-Authority Consensus nedir?](#what-is-decentralized-proof-of-authority-consensus) 16 | - [DPoA fikir birliğinin avantajları](#advantages-of-dpoa-consensus) 17 | - [DPoA fikir birliği ve ortak saldırı araçları](#dpoa-consensus-and-common-means-of-attack) 18 | - [DoS](#dos) 19 | - [51 yüzde saldırı](#percent-attack-51) 20 | - [IBAX'te DPoA konsensüsünün uygulanması](#implementation-of-dpoa-consensus-in-ibax) 21 | - [Honor node](#honor-node) 22 | - [Leader node](#leader-node) 23 | - [Yeni blokların oluşturulması](#generation-of-new-blocks) 24 | - [Forks](#forks) 25 | 26 | ## Decentralized Proof-of-Authority Consensus nedir? {#what-is-decentralized-proof-of-authority-consensus} 27 | 28 | Ticari uygulama senaryolarını ve gerçek dünya ortamlarını göz önünde bulunduran IBAX Ağı, yeni bir fikir birliği mekanizması olan DPoA (Merkezi Olmayan Yetki Kanıtı) oluşturmuştur. 29 | 30 | Ademi merkeziyetçilik her zaman kesin inancımız olmuştur. Yalnızca IBAX'in altyapı ağ ortamını ifade etmez. Bunun yerine, IBAX Ağı'nda oluşturulan her ecoLib'de ademi merkeziyetçiliğin kök salmasına izin vereceğiz ve her birinde yüksek derecede öz yönetim elde etmek için teknik çözümler kullanacağız. Yüksek oranda dağıtılmış öz-yönetim amacıyla, genel mimaride ve teknik uygulamada birçok değişiklik yaptık. Ancak pratikte merkezi yönetim anlayışından kaçamayız. Merkezileşme ve ademi merkeziyetçilik arasında bir denge bulmak için DPoA konsensüs mekanizmasına ek olarak belirli ödül ve teşvik programları da oluşturduk. 31 | 32 | IBAX Ağı, dağıtımı, zayıf merkezileştirmeyi ve bir sertifika yetkilisini birleştiren yeni bir fikir birliği mekanizması yarattı. Biz buna DPoA (Merkezi Olmayan Yetki Kanıtı) diyoruz. Tüm IBAX Ağı için sürekliliği sağlamak için, fikir birliği yalnızca IBAX Kamu Ağı'nı değil, aynı zamanda her kullanıcı ve kullanıcı grubu tarafından oluşturulan ecoLib'leri de kapsar. Bu, gerçekten kendi kendini yöneten, merkezi olmayan, adil, şeffaf ve dolandırıcılığa karşı dayanıklı bir Merkezi Olmayan Otonom Organizasyon (DAO) yaratır. 33 | 34 | DPoA, ağ saldırılarına karşı bir önleme mekanizmasına sahiptir ve ağı koruyan ve yeni IBXC paraları basan Darphane Düğümlerinin oluşturulmasına izin verir. IBAXCoin sahipleri, IBXC likidite bakiyelerinin bir kısmını Mint & Stake Emission Rewards için Mint Nodes'ta stake edebilirler. Darphane ve staking, saldırıların maliyetini ve zorluğunu artırmaya ve IBXC madeni paralarının toplam değerini orantılı olarak artırmaya hizmet eder. Bu mekanizma ile herhangi bir saldırının olasılığı ve zararı sonsuz derecede sıfıra yakındır. 35 | 36 | ## DPoA fikir birliğinin avantajları {#advantages-of-dpoa-consensus} 37 | 38 | İş Kanıtı (PoW) veya Hisse Kanıtı (PoS) konsensüsü ile karşılaştırıldığında, DPoA konsensüsü aşağıdaki avantajlara sahiptir: 39 | 40 | * Yüksek performanslı donanıma ihtiyaç duymaz. PoW konsensüsüyle karşılaştırıldığında, DPoA konsensüsünü uygulayan düğümler, karmaşık matematiksel mantık görevlerini çözmek için hesaplama kaynakları harcamaz; 41 | 42 | * Yeni bloklar oluşturmak için zaman aralığı tahmin edilebilir, ancak PoW ve PoS fikir birliği için bu farklıdır; 43 | 44 | * Yüksek işlem oranı. Bloklar, işlem doğrulama hızını artıran yetkili ağ düğümleri tarafından belirli bir zaman aralığında bir sırayla oluşturulur. 45 | 46 | * Düğümlerin %51'inin güvenliği ihlal edilmediği sürece, güvenliği ihlal edilmiş ve kötü niyetli düğümlere karşı tolerans. IBAX, düğümleri yasaklayan ve blok oluşturma haklarını iptal eden bir mekanizma uygular. 47 | 48 | ## DPoA fikir birliği ve ortak saldırı araçları {#dpoa-consensus-and-common-means-of-attack} 49 | 50 | ### DoS {#dos} 51 | 52 | Saldırgan, ağdaki hedeflenen bir düğüme büyük miktarda işlem ve blok göndererek, çalışmasını kesintiye uğratmaya ve hizmetlerini kullanılamaz hale getirmeye çalışabilir. 53 | 54 | DPoA mekanizmasını DoS saldırılarına karşı savunmak mümkündür: 55 | 56 | * Ağ düğümleri önceden doğrulanmış olduğundan, blok oluşturma hakları yalnızca DoS saldırılarına dayanabilen düğümlere verilebilir. 57 | 58 | * Bir onur düğümü belirli bir süre için kullanılamıyorsa, onur düğümleri listesinden çıkarılabilir. 59 | 60 | ### yüzde 51 saldırı {#percent-attack-51} 61 | 62 | DPoA fikir birliği senaryosuna göre, %51 saldırısı, bir saldırganın ağ düğümlerinin %51'inin kontrolünü ele geçirmesini gerektirir. Ancak, bir saldırganın ağ hesaplama gücünün %51'ini elde etmesi gereken PoW fikir birliği senaryosu farklıdır. İzin verilen bir blok zinciri ağındaki düğümler üzerinde kontrolü elde etmek, hesaplama gücünü elde etmekten çok daha zordur. 63 | 64 | Örneğin, PoW konsensüsünü uygulayan bir ağda, bir saldırgan, kontrollü ağ segmentinin hesaplama gücünü (performansını) artırabilir ve böylece kontrollü düğümlerin yüzdesini artırabilir. Bu, DPoA konsensüsü için bir anlam ifade etmiyor, çünkü düğümün hesaplama gücünün blok zinciri ağ kararları üzerinde hiçbir etkisi yok. 65 | 66 | ## IBAX'te DPoA konsensüsünün uygulanması {#implementation-of-dpoa-consensus-in-ibax} 67 | 68 | ### Honor node {#honor-node} 69 | 70 | IBAX'te yalnızca honor nodeları, blok zinciri ağını ve dağıtılmış defteri tutan yeni bloklar oluşturabilir. 71 | 72 | Onur düğümlerinin listesi, blok zinciri kayıt defterinde tutulur. Düğümlerin sırası, düğümlerin yeni bloklar oluşturma sırasını belirler. 73 | 74 | ### Leader node {#leader-node} 75 | 76 | Aşağıdaki formül, mevcut **leadernode**, yani mevcut zamanda yeni bir blok oluşturması gereken bir düğümü belirler. 77 | 78 | ``` 79 | lider = ((zaman - ilk) / adım) % düğüm 80 | ``` 81 | 82 | > lider 83 | 84 | Mevcut lider düğümü. 85 | 86 | > zaman 87 | 88 | Geçerli saat (UNIX). 89 | 90 | > ilk 91 | 92 | İlk blok oluşturma süresi (UNIX). 93 | 94 | > adım 95 | 96 | Blok oluşturma aralığındaki saniye sayısı. 97 | 98 | > düğümler 99 | 100 | Toplam honor node sayısı. 101 | 102 | ### Yeni blokların oluşturulması {#generation-of-new-blocks} 103 | 104 | Yeni bloklar, geçerli zaman aralığının bir [leader node](#leader-node) tarafından oluşturulur. Her zaman aralığında lider rolü, onur düğümleri listesinden bir sonraki onur düğümüne iletilir. 105 | 106 | ![avatar](/block-generation.png) 107 | 108 | a) Yeni blokların çocukları için 109 | 110 | Yeni bir blok oluşturmak için ana yetiştirme durumumuz: 111 | 112 | 1. Düğümün işindeki tüm yeni işlemler toplar; 113 | 114 | 2. İşlemleri tek tek. Geçersiz veya yürütülemez sahipleri reddedilir; 115 | 116 | 3. [blok oluşturma sınırlarının](../reference/platform-parameters.md#configure-the-generation-of-blocks) uyumlu olup olmadığını kontrol eder; 117 | 118 | 4. Geçerli işlemlere sahip bir blok oluşturur ve bunu ECDSA algoritması aracılığıyla honor node özel anahtarıyla imzalar; 119 | 120 | 5. Bu bloğu diğer onur düğümlerine gönderir. 121 | 122 | b) Yeni blokların doğrulanması 123 | 124 | Diğer onur düğümlerinde yeni blokları doğrulama adımları: 125 | 126 | 1.Yeni bir blok alın ve şunları doğrulayın: 127 | 128 | – yeni bloğun geçerli bir aralığın leader node tarafından oluşturulup oluşturulmadığı; 129 | 130 | – geçerli bir aralığın leader node tarafından oluşturulan başka blok olup olmadığı; 131 | 132 | – yeni bloğun uygun şekilde imzalanıp imzalanmadığı. 133 | 134 | 2. Bloktan işlemleri tek tek gerçekleştirin. İşlemlerin başarılı bir şekilde ve [blok oluşturma sınırları](../reference/platform-parameters.md#configure-the-generasyon-of-blocks) dahilinde yürütülüp yürütülmediğini kontrol edin. 135 | 136 | 3. Önceki adıma bağlı olarak bloğu ekleyin veya reddedin: 137 | 138 | – Blok doğrulama başarılıysa, yeni bloğu mevcut düğümün blok zincirine ekleyin; 139 | 140 | – Blok doğrulama başarısız olursa, bloğu reddedin ve bir **hatalı blok** işlemi gönderin; 141 | 142 | – Bu geçersiz bloğu oluşturan onur düğümü hatalı bloklar oluşturmaya devam ederse, yasaklanabilir veya honor nodeları listesinden çıkarılabilir. 143 | 144 | ### Forks {#forks} 145 | 146 | Bir **fork**, blok zincirinin geri kalanından bağımsız olarak oluşturulmuş bir veya daha fazla blok içeren alternatif bir blok zinciri sürümüdür. 147 | 148 | Çatallar genellikle ağın bir kısmı senkronize olmadığında meydana gelir. Muhtemelen çatallanmalara neden olan faktörler, yüksek ağ gecikmesi, kasıtlı veya kasıtsız zaman sınırı ihlali, düğümlerde zaman senkronizasyonu bozulmasıdır. Ağ düğümlerinin önemli bir coğrafi dağılımı varsa, blok oluşturma aralığı artırılmalıdır. 149 | 150 | Çatallar, en uzun blok zinciri kuralı izlenerek çözülür. İki blok zinciri sürümü algılandığında, onur düğümleri daha kısa olanı geri alır ve daha uzun olanı kabul eder. 151 | 152 | ![avatar](/block-fork-resolution.png) -------------------------------------------------------------------------------- /docs/tr-TR/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # Sunucu Yapılandırma Dosyası {#server-configuration-file} 2 | 3 | Bu bölümde, sunucu yapılandırma dosyasındaki parametreleri tanıtacağız. 4 | ## Sunucu yapılandırma dosyasına giriş {#introduction-to-the-server-configuration-file} 5 | 6 | Sunucu yapılandırma dosyası, IBAX'in düğüm yapılandırmasını tanımlar. 7 | ## Konum {#location} 8 | 9 | Bu dosya sunucunun çalışma dizininde bulunur ve `config.toml` olarak adlandırılır. 10 | ## Bölümler {#sections} 11 | 12 | Yapılandırma dosyası aşağıdaki bölümlerden oluşur: 13 | 14 | > genel bölüm 15 | 16 | DataDir çalışma dizini, FirstBlockPath ilk blok dizini ve diğer parametreleri tanımlar. 17 | 18 | > [TCPServer] 19 | 20 | TCP hizmet parametrelerini tanımlar. 21 | 22 | TCPServer, düğümler arasındaki ağ etkileşimi için kullanılır. 23 | 24 | > [HTTP] 25 | 26 | HTTP hizmet parametrelerini tanımlar. 27 | 28 | HTTPServer, RESTful API'ler sağlar. 29 | 30 | > [DB] 31 | 32 | PostgreSQL düğüm veritabanının parametrelerini tanımlar. 33 | 34 | > [StatsD] 35 | 36 | Düğüm işlem göstergesi toplayıcı StatsD'nin parametrelerini tanımlar. 37 | 38 | > [Centrifugo] 39 | 40 | Centrifugo bildirim hizmetinin parametrelerini tanımlar. 41 | 42 | > [Log] 43 | 44 | Günlük hizmeti Günlüğünün parametrelerini tanımlar. 45 | 46 | > [TokenMovement] 47 | 48 | Token dolaşım hizmeti TokenMovement'in parametrelerini tanımlar. 49 | 50 | ## Örnek bir yapılandırma dosyası {#an-example-configuration-file} 51 | ``` 52 | PidFilePath = "/IBAX-data/go-ibax.pid" 53 | LockFilePath = "/IBAX-data/go-ibax.lock" 54 | DataDir = "/IBAX-data" 55 | KeysDir = "/IBAX-data" 56 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/IBAX-temp" 57 | FirstBlockPath = "/IBAX-data/1block" 58 | TLS = false 59 | TLSCert = "" 60 | TLSKey = "" 61 | OBSMode = "none" 62 | HTTPServerMaxBodySize = 1048576 63 | MaxPageGenerationTime = 3000 64 | NodesAddr = [] 65 | 66 | [TCPServer] 67 | Host = "127.0.0.1" 68 | Port = 7078 69 | 70 | [HTTP] 71 | Host = "127.0.0.1" 72 | Port = 7079 73 | 74 | [DB] 75 | Name = "IBAX" 76 | Host = "127.0.0.1" 77 | Port = 5432 78 | User = "postgres" 79 | Password = "123456" 80 | LockTimeout = 5000 81 | 82 | [StatsD] 83 | Host = "127.0.0.1" 84 | Port = 8125 85 | Name = "IBAX" 86 | 87 | [Centrifugo] 88 | Secret = "127.0.0.1" 89 | URL = "127.0.0.1" 90 | 91 | [Log] 92 | LogTo = "stdout" 93 | LogLevel = "ERROR" 94 | LogFormat = "text" 95 | [Log.Syslog] 96 | Facility = "kern" 97 | Tag = "go-ibax" 98 | 99 | [TokenMovement] 100 | Host = "" 101 | Port = 0 102 | Username = "" 103 | Password = "" 104 | To = "" 105 | From = "" 106 | Subject = "" 107 | ``` 108 | -------------------------------------------------------------------------------- /docs/tr-TR/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # Senkronize İzleme Aracı {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor, belirtilen düğümdeki veritabanının senkronize edilip edilmediğini doğrulamak için kullanılabilecek özel bir araçtır. 4 | 5 | Araç, arka plan programı olarak kullanılabilir veya tek seferlik bir kontrol gerçekleştirmek için başlatılabilir. 6 | 7 | Aletin çalışma prensibi aşağıdakilere dayanmaktadır: 8 | 9 | 1.Her blok, tüm işlemlerin tüm değişikliklerinin karmasını içerir, belirtilen düğümden son blok kimliğini sağlamasını isteyin; 10 | 2.Ardından tüm düğümlerden bu ID ile bir blok talep edin ve yukarıdaki hash'leri karşılaştırın; 11 | 3.Eğer hashler farklı ise, komutta belirtilen e-posta adresine bir senkronizasyon hata mesajı gönderilecektir. 12 | 13 | ## Konum {#location} 14 | Araç, `tools/desync_monitor/` dizininde bulunur. 15 | 16 | ## Komut istemi bayrakları {#command-prompt-flags} 17 | Komut isteminden aşağıdaki bayraklar kullanılabilir: 18 | * confPath - Yapılandırma dosyasının yolu. Varsayılan dosya adı `config.toml`dur; 19 | * nodeList - İstenen bloğun virgülle ayrılmış düğüm listesi. Varsayılan "127.0.0.1:7079"dur; 20 | * daemonMode - Bir arka plan programı olarak başlatılır ve her N saniyede bir kimlik doğrulama gerektiğinde kullanılmalıdır. Bu bayrak varsayılan olarak "yanlış" olarak ayarlanmıştır; 21 | * queryingPeriod - Araç bir arka plan programı olarak başlatılırsa, bu parametre kontroller arasındaki zaman aralığını (saniye cinsinden) varsayılan olarak "1" saniye olarak ayarlar. 22 | * alertMessageTo – Senkronizasyon uyarı hatalarının gönderileceği e-posta adresi. 23 | * alertMessageSubj - Uyarı mesajındaki mesaj konusu, varsayılan olarak `düğüm senkronizasyonu` sorunu; 24 | * alertMessageFrom - Mesajın gönderildiği adres. 25 | * smtpHost - e-posta göndermek için kullanılan SMTP sunucusu ana bilgisayarı, varsayılan olarak `""`; 26 | * smtpPort - e-posta mesajları göndermek için kullanılan SMTP sunucu bağlantı noktası, varsayılan olarak "25"; 27 | * smtpUsername - SMTP sunucusu kullanıcı adı, varsayılan olarak `""`; 28 | * smtpPassword - SMTP sunucu şifresi, varsayılan olarak `""`. 29 | 30 | ## Yapılandırma {#configuration} 31 | Araç, toml formatında bir yapılandırma dosyası kullanır. 32 | 33 | Varsayılan olarak, ikili dosyanın başlatılacağı klasördeki config.toml dosyasını arayacaktır. 34 | 35 | Dosya yolu, configPath bayrağıyla değiştirilebilir. 36 | 37 | ``` 38 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 39 | 40 | [daemon] 41 | daemon = false 42 | querying_period = 1 43 | 44 | [alert_message] 45 | to = "" 46 | subject = "problem with xxx nodes" 47 | from = "" 48 | 49 | [smtp] 50 | host = "" 51 | port = 25 52 | username = "" 53 | password = "" 54 | ``` 55 | 56 | ### node_list {#nodes-list} 57 | * knot_list - Bilgi isteyen düğümlerin (ana bilgisayarların) listesi. 58 | 59 | ### [arka plan programı] {#daemon} 60 | Daemon modunun konfigürasyonu. 61 | * daemon_mode – Bir araç, bir arka plan programı olarak çalışır ve senkronizasyon kontrollerini gerçekleştirir. 62 | * querying_period - Senkronizasyon kontrolleri arasındaki zaman aralığı. 63 | 64 | ### [uyarı mesajı] {#alert-message} 65 | Uyarı mesajı parametreleri. 66 | * için - alıcının senkronizasyon hatası uyarı mesajlarının e-postası; 67 | * konu - mesaj konusu; 68 | * gönderenin e-posta adresinden. 69 | 70 | ### [smtp] {#smtp} 71 | Senkronizasyon hata mesajlarını göndermek için kullanılan Basit Posta Aktarım Protokolü (SMTP) sunucu parametreleri. 72 | * ana bilgisayar – SMTP sunucu host; 73 | * bağlantı noktası –SMTP sunucu bağlantı noktası; 74 | * kullanıcı adı – SMTP sunucusu kullanıcı adı; 75 | * şifre –SMTP sunucu şifresi; -------------------------------------------------------------------------------- /docs/zh-CN/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | home: true 3 | heroImage: /ibax.png 4 | heroText: IBAX 5 | tagline: 一个去中心化的商业跨链基础设施网络 6 | actionText: 快速开始 → 7 | actionLink: /zh-CN/concepts/about-the-platform.html 8 | features: 9 | - title: 大大降低区块链应用成本 10 | - title: 独立构建的物理生态系统 11 | - title: 分布式服务器、开发和应用环境的快速部署 12 | - title: 多元化的 DApp Store 和 BaaS 功能 13 | - title: 秒级实际服务响应 14 | - title: 跨链跨系统数据交互 15 | - title: 集公链、联盟链、私链于一体的新型基础设施网络 16 | - title: 可定制的共识机制 17 | - title: 前后端分离，满足各种加密需求 18 | 19 | footer: © Copyright 2019 - 2023, IBAX Updated Date 06/21/2023 | Built with VuePress 20 | --- 21 | 22 | # IBAX 文档 23 | 24 | ## 概念 25 | * [IBAX区块链平台 概述](concepts/about-the-platform.md) 26 | * [IBAX区块链平台](concepts/blockchain-layers.md) 27 | * [权威证明共识](concepts/consensus.md) 28 | * [术语和定义](concepts/thesaurus.md) 29 | * [常见问题](concepts/faq.md) 30 | 31 | ## 教程 32 | * [应用程序开发教程](tutorials/app_tutorial.md) 33 | * [开发教程](tutorials/tutorial.md) 34 | 35 | ## 指南 36 | * [智能合约](topics/script.md) 37 | * [模版语言](topics/templates2.md) 38 | * [编译器和虚拟机](topics/vm.md) 39 | * [守护进程](topics/daemons.md) 40 | 41 | 42 | ## 参考 43 | * [RESTful API](reference/api2.md) 44 | * [平台参数](reference/platform-parameters.md) 45 | * [服务端配置文件](reference/backend-config.md) 46 | * [同步监控工具](reference/desync_monitor.md) 47 | * [JSON-RPC 应用程序编程接口](reference/json-rpc.md) 48 | 49 | ## 部署 50 | * [IBAX区块链平台 区块链网络部署](howtos/deployment.md) 51 | -------------------------------------------------------------------------------- /docs/zh-CN/concepts/blockchain-layers.md: -------------------------------------------------------------------------------- 1 | # IBAX区块链平台 {#the-ibax-network} 2 | 3 | 4 | - [IBAX区块链平台](#the-ibax-network) 5 | - [应用程序开发者](#application-developers) 6 | - [生态系统成员](#ecolib-members) 7 | - [生态系统应用程序和平台应用程序](#ecolib-applications-and-platform-applications) 8 | - [底层模型](#underlying-model) 9 | - [实现](#implementation) 10 | 11 | 12 | 13 | 该章节介绍如何使用 IBAX区块链平台 。 14 | 15 | 如果您有兴趣在 IBAX区块链平台上开发使用应用程序和管理生态系统，那么您可能根本不需要了解IBAX区块链平台 。 16 | 17 | 在 IBAX区块链平台中，区块链和区块链网络对生态系统成员、管理员和应用程序开发者都是隐藏的。IBAX区块链平台已为所有这些用户组提供了[RESTful API](../reference/api2.md) 接口。这些接口提供对区块链防篡改分布式 **全局状态** 的访问。 18 | 19 | ## 应用程序开发者 {#application-developers} 20 | 21 | 在技术术语中，**全局状态** 是一组数据。IBAX区块链平台全局状态的实现就是数据库。从应用程序开发者的角度来看，应用程序是通过查询，插入和更新数据库表来与该数据库进行交互。 22 | 23 | 在IBAX区块链平台，通过执行合约将交易写入区块链中，这些交易调用由区块链网络节点执行的合约代码， 这会更改全局状态数据库。 24 | 25 | 对于应用程序开发者来说，合约就是一种函数，执行合约时，数据将写入数据库。页面就像脚本。页面代码是一组[页面模版](../topics/templates2.md) 函数。其中一些函数显示页面元素，其他数据来自数据库。应用程序开发者无需了解交易、区块生成和共识算法即可使用IBAX区块链平台。 26 | 27 | ## 生态系统成员 {#ecolib-members} 28 | 29 | 应用程序开发者编写的应用程序在[生态系统](../concepts/thesaurus.md#ecosystem) 的环境中工作，生态系统通常服务于特定的目的，结合多个应用程序来达到该目的的不同方面。 30 | 31 | 要访问生态系统的应用程序，用户必须成为该生态系统成员。一个用户可以是多个生态系统的成员。 32 | 33 | 生态系统成员可以从应用程序页面查看和修改数据库，就像在常见的Web应用程序中一样，可以填写表单，点击按钮和导航页面。 34 | 35 | ## 生态系统应用程序和平台应用程序 {#ecolib-applications-and-platform-applications} 36 | 37 | 应用程序可按范围划分为 **生态系统应用程序** 和 **平台应用程序**。 38 | 39 | > 生态系统应用程序 40 | 41 | 生态系统应用程序实现该生态系统的某些独有功能或业务流程。生态系统应用程序仅在其生态系统中可用。 42 | 43 | > 平台应用程序 44 | 45 | 平台应用程序适用于所有生态系统。任何应用程序都可以开发为平台应用程序。IBAX区块链平台开发者提供支持生态系统治理核心功能的平台应用程序，例如投票、通知和生态系统成员角色管理等应用程序。 46 | 47 | ## 底层模型 {#underlying-model} 48 | 49 | > 层次定义 50 | 51 | IBAX区块链平台 分为几个层次： 52 | 53 | > - 用户交互层 54 | > 55 | > > 生态系统成员通过页面和页面元素与应用程序交互。 56 | > 57 | > - 应用程序层 58 | > 59 | > > 应用程序开发者通过合约代码和页面代码与全局状态（数据库表）交互。 60 | > 61 | > - 全局状态层 62 | > 63 | > > 根据写入分布式操作分类帐本（区块链）的操作更新和同步全局状态（数据库） 64 | > 65 | > - 区块链层 66 | > 67 | > > 使用新区块更新分布式操作分类帐本。新区块保存的操作（交易）必须在全局状态上执行。 68 | > 69 | > - 节点网络层 70 | > 71 | > > 实现了 IBAX区块链平台网络协议。网络协议在节点网络中分发交易、验证交易和生成新区块。同样的，新区块被节点网络分发和验证。所有节点的分布式操作分类帐本保持同步。如果节点发生冲突，则节点会识别哪些区块链被视为有效链并回滚无效区块链。 72 | > 73 | > - 交易层 74 | > 75 | > > 交易是生成区块和区块链协议的基础，交易本身是在用户交互层执行的操作结果。交易由 Weaver 生成。当用户或开发者执行诸如单击页面上的按钮或从代码编辑器执行合约等操作时，Weaver会将此操作转换为交易并将其发送到与其连接的网络节点。 76 | 77 | 因此，交易流程方向如下： 78 | 79 | > - 用户页面中的用户操作会创建交易； 80 | > - 该交易包含在一个区块中； 81 | > - 该区块包含在区块链中； 82 | > - 更改操作会导致区块链全局状态发生变化，该操作将应用于数据库； 83 | > - 数据库更改显示在应用程序中。 84 | 85 | ## 实现 {#implementation} 86 | 87 | IBAX区块链平台 的两个主要组成部分是服务端[go-ibax](https://github.com/IBAX-io/go-ibax) 和 [Wearver源码](https://github.com/IBAX-io/weaver) 。 88 | 89 | Weaver : 90 | > - 提供用户页面； 91 | > 92 | > - 提供用于应用程序开发的IDE； 93 | > 94 | > - 存储用户帐户的公钥并执行授权； 95 | > 96 | > - 从应用页面请求数据库数据，并向用户显示应用页面； 97 | > 98 | > - 通过 [REST API](../reference/api2.md) 将交易发送到服务端； 99 | > 100 | > > 为了方便用户操作自动创建交易，应用程序开发人员从IDE执行合约时，Weaver会将该操作转换为交易。 101 | 102 | 服务端： 103 | 104 | > - 保持节点的全局状态（数据库）； 105 | > - 实现区块链协议； 106 | > - 在 [虚拟机](../topics/vm.md) 执行合约代码； 107 | > - 在 [模版引擎](../topics/templates2.md) 执行页面代码； 108 | > - 实现 [RESTful API](../reference/api2.md) 接口。 109 | -------------------------------------------------------------------------------- /docs/zh-CN/concepts/consensus.md: -------------------------------------------------------------------------------- 1 | # 权威证明共识 {#decentralized-proof-of-authority-consensus} 2 | 3 | 4 | - [什么是去中心化权威证明共识](#what-is-decentralized-proof-of-authority-consensus) 5 | - [DPoA共识优势](#advantages-of-dpoa-consensus) 6 | - [DPoA共识常见攻击手段](#dpoa-consensus-and-common-means-of-attack) 7 | - [拒绝服务攻击](#dos) 8 | - [51%攻击](#percent-attack-51) 9 | - [IBAX中DPoA共识的实现](#implementation-of-dpoa-consensus-in-ibax) 10 | - [荣誉节点](#honor-node) 11 | - [领导节点](#leader-node) 12 | - [生成新区块](#generation-of-new-blocks) 13 | - [分叉](#forks) 14 | 15 | 16 | 17 | 该章节描述权威证明共识及其在 IBAX区块链平台 中的实现。 18 | 19 | ## 什么是去中心化权威证明共识 {#what-is-decentralized-proof-of-authority-consensus} 20 | 21 | IBAX Network考虑商业应用场景和现实环境，构建了一种新的共识机制DPoA（Decentralized Proof of Authority）。 22 | 23 | 去中心化一直是我们坚定的信念。 它不仅仅指 IBAX 的基础设施网络环境。 相反，我们将让去中心化在 IBAX Network 中创建的每个 ecoLib 中生根，并使用技术解决方案在每个生态中实现高度自治。 为了实现高度分布式的自治，我们在整体架构和技术实现上做了很多改动。 但是，在实践中，我们不能避免集中管理的概念。 为了在中心化和去中心化之间找到平衡点，除了DPoA共识机制，我们还制定了一定的奖励和激励方案。 24 | 25 | IBAX 网络创建了一种新的共识机制，将分布式、弱中心化和证书授权相结合。 我们称之为 DPoA（去中心化的权威证明）。 为了保证整个 IBAX 网络的连续性，共识不仅包括 IBAX 公共网络，还包括每个用户和用户组创建的 ecoLibs。这将创建一个真正自治、去中心化、公平、透明和防欺诈的去中心化自治组织 (DAO)。 26 | 27 | DPoA 具有防止网络攻击的机制，并允许创建保护网络和铸造新 IBXC 代币的铸币节点。 IBAXCoin 持有者可以将其 IBXC 流动性余额的一部分质押在 Mint 节点中，以获得 Mint & Stake Emission Rewards。铸造和质押有助于增加攻击的成本和难度，并按比例增加 IBXC 币的总价值。 有了这种机制，任何攻击的概率和危害都无限接近于零。 28 | 29 | ## DPoA共识优势 {#advantages-of-dpoa-consensus} 30 | 31 | 与工作量证明PoW和权益证明PoS共识机制相比，DPoA具有以下几点优势： 32 | 33 | - 不需要高性能硬件，与PoW共识相比，DPoA共识不要求节点花费计算资源来解决复杂的数学逻辑； 34 | - 生成新区块的时间间隔可预测，对于PoW和PoS共识，这个时间会有所不同； 35 | - 高交易率，授权的网络节点按指定的时间间隔按顺序生成块，这提高了交易验证的速度； 36 | - 容忍被攻击和恶意节点，只要51％的节点不受攻击。IBAX区块链平台实现了节点的禁止和撤销区块生成权的机制。 37 | 38 | ## DPoA共识常见攻击手段 {#dpoa-consensus-and-common-means-of-attack} 39 | 40 | ### 拒绝服务攻击 {#dos} 41 | 42 | 攻击者向目标网络节点发送大量交易和区块，试图中断节点活动使其不可用。 43 | 44 | DPoA机制可以抵御这种攻击： 45 | 46 | > - 由于网络节点已预先通过身份验证，因此只能为可承受DoS攻击的节点授予区块生成权限； 47 | > - 如果某个荣誉节点在一段时间内不可用，则可以将其从荣誉节点列表中排除。 48 | 49 | ### 51%攻击 {#percent-attack-51} 50 | 51 | 在DPoA共识中，51％的攻击要求攻击者获得对51％的网络节点的控制权。这与攻击者需要获得51％的网络计算能力的Pow共识的51％攻击不同。获得许可区块链网络中的节点控制权比获得计算能力要困难得多。 52 | 53 | 例如，在PoW共识网络中，攻击者可以增加受控网络段的计算能力（性能），从而增加受控百分比。这对于DPoA共识没有意义，因为节点的计算能力对区块链网络决策没有影响。 54 | 55 | ## IBAX中DPoA共识的实现 {#implementation-of-dpoa-consensus-in-ibax} 56 | 57 | ### 荣誉节点 {#honor-node} 58 | 59 | 在 IBAX区块链平台 只有 荣誉节点才有权产生新区块，这些节点维护区块链网络和分布式账本。 60 | 61 | 荣誉节点列表保存在区块链注册表中。此列表中的节点顺序决定了节点生成新区块的顺序。 62 | 63 | #### 领导节点 {#leader-node} 64 | 领导节点是在当前时间生成新区块的荣誉节点，以下公式确定当前荣誉节点列表中的领导节点: 65 | 66 | ``` text 67 | leader = ((time - first) / step) % nodes 68 | ``` 69 | 70 | > leader 71 | 72 | 当前荣誉节点列表的索引，根据索引即可表示其为领导节点。 73 | 74 | > time 75 | 76 | 当前时间（UNIX）。 77 | 78 | > first 79 | 80 | 创始区块生成时间 (UNIX）。 81 | 82 | > step 83 | 84 | 区块生成间隔中的秒数。 85 | > nodes 86 | 87 | 荣誉节点总数量。 88 | 89 | #### 生成新区块 {#generation-of-new-blocks} 90 | 91 | 新区块由当前时间间隔的[领导节点](#leader-node)生成。在每个时间间隔，领导节点从荣誉节点列表传递到下一个荣誉节点。 92 | 93 | ![image](/block-generation.png) 94 | 95 | a) 新区块生成步骤 96 | 97 | 主要步骤如下： 98 | 99 | > 1. 从节点的交易队列中收集所有新交易； 100 | > 2. 逐个执行交易，无效或无法执行的交易将被拒绝； 101 | > 3. 检查是否符合[区块生成限制范围](../reference/platform-parameters.md#configure-the-generation-of-blocks) ； 102 | > 4. 生成具有有效交易的新区块，并使用荣誉节点的节点私钥通过ECDSA算法对其区块进行签名； 103 | > 5. 将该区块发送到其他荣誉节点。 104 | 105 | b) 验证新区块 106 | 107 | 其他荣誉节点验证步骤: 108 | 109 | > 1. 接收并验证新区块: 110 | > 111 | > > - 新区块是否由当前时间间隔的 领导节点 生成； 112 | > > - 当前时间间隔的 领导节点 没有生成其他区块； 113 | > > - 新区块被正确签名。 114 | > 115 | > 2. 逐个执行区块中的交易。检查交易是否成功执行并且在[区块生成限制范围](../reference/platform-parameters.md#configure-the-generation-of-blocks) 内。 116 | > 117 | > 3. 接受或拒绝该区块，具体取决于上一步: 118 | > 119 | > > - 如果区块验证成功，则将新区块添加到当前节点的区块链中； 120 | > > - 如果区块验证失败，则拒绝该区块，标记该区块并发送 **坏区块**交易； 121 | > > - 如果生成坏区块的荣誉节点继续生成该类坏区块，则可以从荣誉节点列表中禁用或排除该荣誉节点。 122 | 123 | ### 分叉 {#forks} 124 | 125 | **分叉**是区块链的替代版本。分叉包含一个或多个独立于区块链其余部分生成的区块。 126 | 127 | 分叉通常在发生网络节点的一部分不同步，影响分叉概率的因素是高网络延迟，有意或无意的时间限制违规，节点的系统时间不同步。如果网络节点具有显着的地理分布，则必须增加区块生成间隔。 128 | 129 | 通过遵循最长的区块链规则来解析分叉。当检测到两个版本的区块链时，荣誉节点将回滚较短版本并接受较长版本。 130 | 131 | ![image](/block-fork-resolution.png) -------------------------------------------------------------------------------- /docs/zh-CN/concepts/faq.md: -------------------------------------------------------------------------------- 1 | # 常见问题 {#faq} 2 | 3 | - [1. 请简短描述一下 IBAX区块链平台?](#question-1) 4 | - [2. IBAX区块链平台 是否适用于比特币、以太坊或其他区块链？](#question-2) 5 | - [3. 其他内置执行智能合约机制的公共区块链平台的主要区别是什么?](#question-3) 6 | - [4. 有自己的加密货币吗？](#question-4) 7 | - [5. 什么是荣誉节点，谁可以维护？](#question-5) 8 | - [6. 什么是平台生态系统？](#question-6) 9 | - [7. 谁可以创建生态系统？](#question-7) 10 | - [8. 用户如何成为生态系统的成员？](#question-8) 11 | - [9. 一位用户可以创建多个生态系统吗？](#question-9) 12 | - [10. 什么是平台应用程序？](#question-10) 13 | - [11. 什么编程语言用于创建应用程序？](#question-11) 14 | - [12. 什么软件用于创建应用程序和用户交互?](#question-12) 15 | - [13. 平台合约可以使用第三方API接口访问数据吗？](#question-13) 16 | - [14. 保存在区块链中的合约可以更改吗？](#question-14) 17 | - [15. 什么是智能法律？](#question-15) 18 | - [16. 合约可以调用执行其他合约吗？](#question-16) 19 | - [17. 应用程序工作是否需要主合约？](#question-17) 20 | - [18. 应用程序可以为不同语言本地化吗？](#question-18) 21 | - [19. 可以在不使用模版语言的情况下创建页面吗?](#question-19) 22 | - [20. 页面是否存储在区块链中？](#question-20) 23 | - [21. 哪些类型的数据库可以用于合约的操作？](#question-21) 24 | - [22. 如何管理对数据表中数据的访问？](#question-22) 25 | - [23. 生态系统中的应用程序可以与来自另一个生态系统的应用程序交换数据吗？](#question-23) 26 | - [24. 是否应该从头开始编写新生态系统中的所有应用程序？](#question-24) 27 | - [25. 应用程序的运作是否有任何费用?](#question-25) 28 | - [26. 谁支付应用程序的运作费用？](#question-26) 29 | - [27. 如何保护生态系统内的应用程序免受其漏洞的攻击？](#question-27) 30 | - [28. 在未来的计划中实现哪些新功能？](#question-28) 31 | - [29. 如何证明可操作性?](#question-29) 32 | 33 | ## 1. 请简短描述一下 IBAX区块链平台? {#question-1} 34 | 35 | - 是一个区块链平台，旨在构建一个基于集成应用程序开发环境的数字生态系统，该环境具有用于管理数据、接口和智能合约访问权限的多级权限系统。 36 | 37 | ## 2. IBAX区块链平台 是否适用于比特币、以太坊或其他区块链？ {#question-2} 38 | 39 | - 不适用 IBAX区块链平台 构建在自身原始区块链的基础上。 40 | 41 | ## 3. 其他内置执行智能合约机制的公共区块链平台的主要区别是什么? {#question-3) 42 | 43 | - IBAX区块链平台 具有上述区块链无法找到的独特功能： 44 | - 在单个客户端软件中实现集成应用程序开发环境； 45 | - 用于页面设计的专用模版语言 Logicor 与合约语言 Needle相互协调； 46 | - 具有用于管理数据、接口和智能合约访问权限的多级权限系统，其中可以将权限授予成员、角色和合约； 47 | - 生态系统，用于创建区块链应用程序和用户与其交互的自治软件环境； 48 | - 法律体系，一套以智能法律(专用的智能合约)编写的规则，规范了平台用户之间的关系，定义了用于解决问题的协议参数变化过程。 49 | 50 | ## 4. 有自己的加密货币吗？ {#question-4} 51 | 52 | - 有，IBAX区块链平台使用自己的通证IBXC。 53 | 54 | ## 5. 什么是荣誉节点，谁可以维护？ {#question-5} 55 | 56 | - 荣誉节点 是有权验证交易和生成新区块的网络节点。 57 | - 具有足够处理能力和容错能力的任何网络节点都可以成为荣誉节点。 58 | IBAX区块链平台使用权威证明（DPoA）共识机制，节点可以基于生态系统的投票成为验证节点， 59 | 但只有被平台通证拥有者证明具有正常运作能力的生态系统才能参与此类投票。 60 | 使用这种授权算法，荣誉节点由主要生态系统运行，因为维护网络运行最符合他们的利益。 61 | 62 | ## 6. 什么是平台生态系统？ {#question-6} 63 | 64 | - 生态系统实际上是用于创建区块链应用程序和其中用户的操作的自治软件环境。 65 | 66 | ## 7. 谁可以创建生态系统？ {#question-7} 67 | 68 | - 平台的所有用户都可以创建新的生态系统。 69 | 70 | ## 8. 用户如何成为生态系统的成员？ {#question-8} 71 | 72 | - 平台网络的生态系统成员注册可在现有任何生态系统中进行，生态系统的策略定义了不同的成员加入程序，该策略在专门的生态系统目录中发布了新生态系统的关键公开信息。 73 | 74 | ## 9. 一位用户可以创建多个生态系统吗？ {#question-9} 75 | 76 | - 是的，每位用户都可以创建任意数量的生态系统，同时也可以成为多个生态系统的成员。 77 | 78 | ## 10. 什么是平台应用程序？ {#question-10} 79 | 80 | - 应用程序是实现功能或服务的完整软件产品。应用程序由数据库表、合约和页面组成。 81 | 82 | ## 11. 什么编程语言用于创建应用程序？ {#question-11} 83 | 84 | - 合约使用 Needle 语言编写，该语言由平台团队开发，更多参阅： 85 | [智能合约](../topics/script.md) 86 | - 页面使用 Logicor 语言编写，是一种页面模版语言，更多参阅： 87 | [模版语言](../topics/templates2.md) 88 | 89 | ## 12. 什么软件用于创建应用程序和用户交互? {#question-12} 90 | 91 | - 应用程序在 Weaver 中编写和执行，不需要其他软件。 92 | 93 | ## 13. 平台合约可以使用第三方API接口访问数据吗？ {#question-13} 94 | 95 | - 不可以，合约只能直接访问区块链中存储的数据，[CLB](about-the-platform.md#虚拟专用生态系统)用于处理外部数据源。 96 | 97 | ## 14. 保存在区块链中的合约可以更改吗？ {#question-14} 98 | 99 | - 是的，合约可以更改。更改合约的权限由其创建者指定，合约创建者可以指定拒绝更改的权限，或者指定合约和成员进行更改的权限，或者在智能法律中配置一组复杂的条件。 100 | - Weaver 提供对所有合约版本的访问。 101 | 102 | ## 15. 什么是智能法律？ {#question-15} 103 | 104 | - 智能法律是一种合约，旨在控制和限制常规合约的运作，从而控制和限制生态系统成员的活动。 105 | - 一套智能法律可以被视为一个生态系统的法律体系。 106 | 107 | ## 16. 合约可以调用执行其他合约吗？ {#question-16} 108 | 109 | - 可以，合约可以通过直接寻址的方式并为其提供参数来调用其他合约，或者通过链接名称调用合约，更多参阅：[智能合约](../topics/script.md) 110 | 111 | ## 17. 应用程序工作是否需要主合约？ {#question-17} 112 | 113 | - 不需要，合约是执行某些功能的自治程序模块。每个合约配置了接收指定的数据，然后检查这些数据的正确性，并执行一些操作，这些操作当作交易被记录在数据库。 114 | 115 | ## 18. 应用程序可以为不同语言本地化吗？ {#question-18} 116 | 117 | - 可以，Weaver拥有内置的本地化支持机制，可以创建任何语言的页面。 118 | 119 | ## 19. 可以在不使用模版语言的情况下创建页面吗? {#question-19} 120 | 121 | - 可以，使用平台 [RESTful API](../reference/api2.md) 可以做到。 122 | 123 | ## 20. 页面是否存储在区块链中？ {#question-20} 124 | 125 | - 是的，页面和合约都存储在区块链中，这可以防止它们被伪造。 126 | 127 | ## 21. 哪些类型的数据库可以用于合约的操作？ {#question-21} 128 | 129 | - 目前使用PostgreSQL数据库。 130 | 131 | ## 22. 如何管理对数据表中数据的访问？ {#question-22} 132 | 133 | - 可以为生态系统成员、角色或指定合约配置添加新字段、新条目或更改列中数据的权限。但执行特定操作而创建的合约除外。 134 | 135 | ## 23. 生态系统中的应用程序可以与来自另一个生态系统的应用程序交换数据吗？ {#question-23} 136 | 137 | - 可以，通过适用于所有生态系统的全局数据表可以组织数据交换。 138 | 139 | ## 24. 是否应该从头开始编写新生态系统中的所有应用程序？ {#question-24} 140 | 141 | - 不需要，每个新的生态系统都有一些开箱即用的应用程序: 142 | - 管理生态系统成员和角色的机制； 143 | - 发行和配置其他通证； 144 | - 投票系统； 145 | - 通知系统； 146 | - 生态系统成员间的消息通信。 147 | 148 | 可以对这些应用程序进行编辑和配置，以满足任何生态系统的特殊需求。 149 | 150 | ## 25. 应用程序的运作是否有任何费用? {#question-25} 151 | 152 | - 是的，使用荣誉节点的资源需要在平台中支付通证。 153 | 154 | ## 26. 谁支付应用程序的运作费用？ {#question-26} 155 | 156 | 相应的账户地址，目前有4种方式支付应用程序的运作费用： 157 | 158 | - 合约调用者，默认账户地址，当用户调用合约时，该用户的账户地址支付； 159 | - 合约绑定者，合约创建者指定的账户地址，所有用户调用该合约的费用，由该账户地址支付； 160 | - 生态系统创建者，生态系统内所有应用程序的运作费用由生态系统创建者支付； 161 | - 生态系统专属钱包，每个生态系统都有独有的账户地址，如果生态系统创建者激活了该账户地址，生态系统内所有应用程序的运作费用由该账户地址支付。 162 | 163 | 支付优先级：*生态系统专属钱包* > *生态系统创建者* > 164 | *合约绑定者* > *合约调用者*。 165 | 166 | ## 27. 如何保护生态系统内的应用程序免受其漏洞的攻击？ {#question-27} 167 | 168 | - 平台团队也知道没有办法完全避免应用程序代码中的错误，特别是考虑到应用程序可以由任何用户编写。这就是我们决定建立一种消除利用漏洞后果机制的原因。法律体系可以停止应用程序的攻击操作，并使用一些交易来恢复到原来状态。法律体系中规定了执行该类合约的权限和授予这些权限的投票程序。 169 | 170 | ## 28. 在未来的计划中实现哪些新功能？ {#question-28} 171 | 172 | - 可视化智能合约设计器； 173 | - 支持混合数据库(SQL和NoSQL) ； 174 | - 来自不同生态系统的交易的并行多线程处理； 175 | - 在客户端执行资源密集型计算； 176 | - 生态系统托管和计算能力交换； 177 | - 轻节点，只存储服务器上部分区块； 178 | - 语义参考（本体）用于统一平台内数据的操作等。 179 | 180 | ## 29. 如何证明可操作性? {#question-29} 181 | 182 | - 在 IBAX区块链平台上实施了一系列概念论证项目和案例：社会化代收税及电子发票生成和流转系统、医疗器械监管及防伪追溯系统、融资及监管系统、投票/民调系统、工商登记、贸易金融工具、资产登记合约管理系统等。 183 | -------------------------------------------------------------------------------- /docs/zh-CN/concepts/thesaurus.md: -------------------------------------------------------------------------------- 1 | # 术语和定义 {#terms-and-definitions} 2 | 3 | - [区块链相关术语](#blockchain-terms) 4 | - [区块链](#blockchain) 5 | - [对等网络](#peer-to-peer-network) 6 | - [哈希](#hash) 7 | - [区块](#block) 8 | - [区块验证](#block-verification) 9 | - [共识](#consensus) 10 | - [通证](#token) 11 | - [标识符](#identification) 12 | - [唯一标识符](#unique-identification) 13 | - [私钥](#private-key) 14 | - [公钥](#public-key) 15 | - [数字签名](#digital-signature) 16 | - [智能合约](#smart-contract) 17 | - [交易费用](#transaction-fee) 18 | - [双重支付](#double-spend) 19 | - [加密](#encryption) 20 | - [私有链](#private-blockchain) 21 | - [公有链](#public-blockchain) 22 | - [权威证明](#proof-of-authority) 23 | - [IBAX区块链平台术语](#ibax-terms) 24 | - [测试网](#testnet) 25 | - [主网](#mainnet) 26 | - [燃料](#gas-fee) 27 | - [账户地址](#account-address) 28 | - [钱包地址](#wallet-address) 29 | - [Weaver](#weaver) 30 | - [生态系统](#ecolib) 31 | - [生态系统参数](#ecolib-parameters) 32 | - [生态系统成员](#ecolib-members) 33 | - [虚拟专用生态系统](#virtual-private-ecolib) 34 | - [去中心化权威证明](#decentralized-proof-of-authority) 35 | - [Needle](#needle) 36 | - [Logicor](#logicor) 37 | - [集成开发环境](#integrated-development-environment-ide) 38 | - [页面编辑器](#page-editor) 39 | - [可视化页面设计器](#visual-page-designer) 40 | - [合约编辑器](#contract-editor) 41 | - [多语言资源](#multilingual-resources) 42 | - [导出应用程序](#application-export) 43 | - [导入应用程序](#application-import) 44 | - [智能法律](#smart-law) 45 | - [法律制度](#legal-system) 46 | - [应用程序](#application) 47 | - [页面](#page) 48 | - [代码片段](#code-segment) 49 | - [访问权限](#access-rights) 50 | - [荣誉节点](#honor-node) 51 | - [守护节点](#guardian-node) 52 | - [并发事务处理](#concurrent-transaction-processing) 53 | 54 | 55 | 56 | ## 区块链相关术语 {#blockchain-terms} 57 | 58 | ### 区块链 {#blockchain} 59 | 60 | > 一种存储数据的信息系统，在系统内传输和处理数据，可以防止数据被伪造和丢失，同时保持数据可靠性； 通过以下方式实现数据保护： 61 | > 62 | > > 1. 将数据写入一系列加密区块的区块链中； 63 | > > 2. 在对等网络中分散存储区块链副本； 64 | > > 3. 使用共识机制对所有节点上的区块链进行同步； 65 | > > 4. 通过在区块链中存储数据传输和处理合约的算法，确保在使用网络执行数据操作时，保证数据可靠性。 66 | 67 | ### 对等网络 {#peer-to-peer-network} 68 | 69 | > 由计算机网络的对等节点组成（没有中央服务器）。 70 | 71 | ### 哈希 {#hash} 72 | 73 | > 又叫做散列，任意文件或数据集长度的二进制值映射为较短的固定长度的二进制值。 74 | 75 | ### 区块 {#block} 76 | 77 | > 在验证交易的格式和签名之后，由荣誉节点分组到特定数据结构中的交易集合。一个区块包含一个哈希指针作为到前一个区块的链接，这是确保区块链加密安全性的措施之一。 78 | 79 | ### 区块验证 {#block-verification} 80 | 81 | > 验证区块结构、生成时间、与前一个区块的兼容性、交易签名以及交易与区块数据的对应关系的正确性。 82 | 83 | ### 共识 {#consensus} 84 | 85 | > 荣誉节点 在向区块链添加新区块过程中使用的验证协议或该类协议的算法。 86 | 87 | ### 交易 {#transaction-1} 88 | 89 | > 区块链网络上的数据传输操作或区块链中该类事务的记录。 90 | 91 | ### 通证 {#token} 92 | 93 | > 区块链上可流通的加密数字权益证明。存储在寄存器中的一组可识别的数字记录，包括在这些记录之间交换权利份额的机制。 94 | 95 | ### 标识符 {#identification} 96 | 97 | > 用于识别系统中用户的加密程序。 98 | 99 | ### 唯一标识符 {#unique-identification} 100 | 101 | > 将账户和用户联系起来的程序，需要法律和组织的努力或其他程序来实现生物识别，以便将用户名与实际用户联系起来。 102 | 103 | ### 私钥 {#private-key} 104 | 105 | > 由其拥有者密存的一串字符串，用于该拥有者访问在网络上的虚拟帐户并签署交易。 106 | 107 | ### 公钥 {#public-key} 108 | 109 | > 用于检查私钥真实性的一串字符，公钥由私钥唯一派生生成。 110 | 111 | ### 数字签名 {#digital-signature} 112 | 113 | > 文档或消息经数据加密处理后获得的属性，数字签名用于检查文档的完整性（没有修改）和真实性（验证发件人的身份）。 114 | 115 | ### 智能合约 {#smart-contract} 116 | 117 | > 在区块链中的执行数据存储操作的程序，所有合约都存储在区块链中。 118 | 119 | ### 交易费用 {#transaction-fee} 120 | 121 | > 向荣誉节点支付执行交易的费用。 122 | 123 | ### 双重支付 {#double-spend} 124 | 125 | > 一种对区块链网络攻击方法，结果是一笔交易花费两次同样的通证。 126 | > 127 | > 在区块链分叉时会导致这种攻击发生。只有当攻击者控制了网络验证能力的50%以上时，才能执行该类攻击。 128 | 129 | ### 加密 {#encryption} 130 | 131 | > 一种数字数据转换的方式，只有拥有对应解密密钥的一方才能读取它。 132 | 133 | ### 私有链 {#private-blockchain} 134 | 135 | > 所有节点和数据访问权限由单个组织（政府、公司或私人）集中控制的区块链网络。 136 | 137 | ### 公有链 {#public-blockchain} 138 | 139 | > 不受任何组织控制的区块链网络，所有决策都是通过在网络参与者之间达成共识来决定，每个人都可以获取和访问区块链网络的数据。 140 | 141 | ### 权威证明 {#proof-of-authority} 142 | > 权威证明（PoA），IBAX 网络创建了一种新的共识机制，将分布式、弱中心化和证书授权相结合。 我们称之为 PoA（权威证明）。 为了保证整个 IBAX 网络的连续性，共识不仅包括 IBAX 公共网络，还包括每个用户和用户组创建的 ecoLibs。 这将创建一个真正自治、去中心化、公平、透明和防欺诈的去中心化自治组织 (DAO)。 143 | 144 | ## IBAX区块链平台术语 {#ibax-terms} 145 | 146 | ### 测试网 {#testnet} 147 | 148 | > 用于测试的区块链网络版本。 149 | 150 | ### 主网 {#mainnet} 151 | 152 | > 区块链网络主版本。 153 | 154 | ### 交易事务 {#transaction-2} 155 | 156 | > 调用合约并将参数传递给合约的操作命令，荣誉节点执行交易的结果是数据库的更新。 157 | 158 | ### 燃料 {#gas-fee} 159 | 160 | > 用于计算在节点网络上执行某些操作的费用的常规单位，燃料汇率由 荣誉节点投票决定。 161 | 162 | ### 账户地址 {#account-address} 163 | 164 | > 存储通证的数据记录，可以通过一对密钥（私钥和公钥）访问。 165 | 166 | ### 钱包地址 {#wallet-address} 167 | 168 | > 节点网络上用户的字符编码标识符，作为该用户的虚拟帐户的名称。 169 | 170 | ### Weaver {#weaver} 171 | 172 | > 用于连接节点网络的软件客户端，有桌面版本和Web浏览器版本。 173 | > 174 | > Weaver 集成了平台开发环境，包括创建和编辑数据表、页面和合约。用户可在 Weaver 构建生态系统、创建和使用应用程序。 175 | 176 | ### 生态系统 {#ecolib} 177 | 178 | > 一个相对封闭或开放的软件编程环境，包括了应用程序和生态系统成员。 179 | > 180 | > 生态系统成员可以发行属于生态系统的专属通证、使用智能合约建立成员间的交互规则、设置成员访问应用程序元素的权限。 181 | 182 | ### 生态系统参数 {#ecolib-parameters} 183 | 184 | > 一组可配置的生态系统参数，有生态系统创建者账户、更改应用程序元素权限等参数，在参数表中可更改。 185 | 186 | ### 生态系统成员 {#ecolib-members} 187 | 188 | > 可以访问特定生态系统和应用程序功能的用户。 189 | 190 | ### 虚拟专用生态系统 {#virtual-private-ecolib} 191 | 192 | > 虚拟专用生态系统 Cross Ledgers Base （ CLB ），它具有标准生态系统的全套功能，但在区块链之外工作。 在 CLB中，可以使用和创建合约和模板语言、数据库表，可以使用 Weaver创建应用程序。 可以使用接口方式调用区块链生态系统上的合约。 193 | 194 | ### 去中心化权威证明 {#decentralized-proof-of-authority} 195 | 196 | > 去中心化权威证明（DPoA）是一种新的共识算法，可提供高性能和容错性。 在 DPoA 中，生成新区块的权利授予已经证明有这样做的节点，并且这些节点必须经过初步验证。 197 | 198 | ### Needle {#needle} 199 | 200 | > 用于创建智能合约的脚本语言，可以处理从用户页面接收的数据功能，以及用于在数据库表中执行的值操作。 201 | > 202 | > 可以在 Weaver 的编辑器中创建和编辑合约。 203 | 204 | ### Logicor {#logicor} 205 | 206 | > 用于创建页面的模版语言，可以从数据库表中获取值、构建用户页面、 将用户输入数据传递到合约的**data** 部分。 207 | 208 | ### 集成开发环境 {#integrated-development-environment-ide} 209 | 210 | > 集成开发环境Integrated Development Environment（IDE）是一组用于创建应用程序的软件工具。 211 | > 212 | > Weaver的集成开发环境包括合约编辑器，页面编辑器，数据库表管理工具，多语言资源编辑器以及应用程序导出和导入功能。集成开发环境与基于语义工具的可视化页面设计器相辅相成。 213 | 214 | ### 页面编辑器 {#page-editor} 215 | 216 | > Weaver 中通过直接在屏幕上排列基本应用程序元素HTML容器，表单域，按钮等工具， 可以来创建应用程序页面。 217 | 218 | ### 可视化页面设计器 {#visual-page-designer} 219 | 220 | > Weaver 中创建应用程序页面的工具，包括界面设计器和 Logicor语言的页面代码生成器。 221 | 222 | ### 合约编辑器 {#contract-editor} 223 | 224 | > Weaver 中使用可视化页面创建合约的工具。 225 | 226 | ### 多语言资源 {#multilingual-resources} 227 | 228 | > Weaver中应用程序页面本地化的模块，它将应用程序页面上的标签与所选语言的文本值相关联。 229 | 230 | ### 导出应用程序 {#application-export} 231 | 232 | > 将应用程序的所有数据表、页面和合约等源代码保存为文件。 233 | 234 | ### 导入应用程序 {#application-import} 235 | 236 | > 将应用程序包含在导出文件中的所有数据表，页面和合约加载到生态系统中。 237 | 238 | ### 智能法律 {#smart-law} 239 | 240 | > 是包含监管信息的一组特殊智能合约。用于管理控制合约的操作和寄存器访问权限。 241 | 242 | ### 法律制度 {#legal-system} 243 | 244 | > 在智慧法律中制定的一套规则机制，该规则可以规范生态系统用户之间的关系，定义更改协议参数的程序规则，还有定义各种具有挑战性的解决方案。 245 | 246 | ### 应用程序 {#application} 247 | 248 | > 在 Weaver 的集成开发环境中创建功能完备的软件产品。 249 | > 250 | > 应用程序是具有配置访问权限的数据库表、智能合约和用户页面等元素的集合。 251 | 252 | ### 页面 {#page} 253 | 254 | > 使用 Logicor 模板语言编写的程序代码从而在屏幕上形成一个可交互的界面。 255 | 256 | ### 代码片段 {#code-segment} 257 | 258 | > 使用 Logicor 模板语言编写的程序代码，可以重复包含在应用程序页面中的代码块。 259 | 260 | ### 访问权限 {#access-rights} 261 | 262 | > 获取创建和编辑数据表，合约和页面的访问权限的条件。 263 | > 264 | > 对数据表的访问权限可以设置添加行和列，以及编辑列中值的权限。 265 | 266 | ### 荣誉节点 {#honor-node} 267 | 268 | > 网络节点中有权生成和验证区块的节点。 269 | 270 | ### 守护节点 {#guardian-node} 271 | 272 | > 网络上的一个节点，用于存储完整区块链的最新版本。 273 | 274 | ### 并发事务处理 {#concurrent-transaction-processing} 275 | 276 | > 一种通过同时处理来自不同生态系统的数据来提高交易处理速度的方法。 277 | -------------------------------------------------------------------------------- /docs/zh-CN/reference/backend-config.md: -------------------------------------------------------------------------------- 1 | # 服务端配置文件 {#server-configuration-file} 2 | 3 | 该章节介绍服务端配置文件参数。 4 | 5 | ## 服务端配置文件简介 {#introduction-to-the-server-configuration-file} 6 | 7 | 服务端配置文件定义了 IBAX区块链平台 节点的配置。 8 | 9 | ## 位置 {#location} 10 | 11 | 该文件位于服务端工作目录下，名为 `config.toml`。 12 | 13 | ## 部分 {#sections} 14 | 15 | 配置文件有以下几个部分： 16 | 17 | > 普通部分 18 | 19 | 定义工作目录DataDir，第一个区块目录FirstBlockPath等参数。 20 | 21 | > [TCPServer] 22 | 23 | 定义TCP服务参数。 24 | 25 | TCPServer用于节点之间的网络交互。 26 | 27 | > [HTTP] 28 | 29 | 定义HTTP服务参数。 30 | 31 | HTTPServer提供RESTful API。 32 | 33 | > [DB] 34 | 35 | 定义节点数据库PostgreSQL的参数。 36 | 37 | > [StatsD] 38 | 39 | 定义节点操作指标收集器StatsD的参数。 40 | 41 | > [Centrifugo] 42 | 43 | 定义通知服务Centrifugo的参数。 44 | 45 | > [Log] 46 | 47 | 定义了日志服务Log的参数。 48 | 49 | > [TokenMovement] 50 | 51 | 定义了通证流通服务TokenMovement的参数。 52 | 53 | ## 配置文件示例 {#an-example-configuration-file} 54 | 55 | ``` js 56 | PidFilePath = "/ibax-data/go-ibax.pid" 57 | LockFilePath = "/ibax-data/go-ibax.lock" 58 | DataDir = "/ibax-data" 59 | KeysDir = "/ibax-data" 60 | TempDir = "/var/folders/_l/9md_m4ms1651mf5pbng1y1xh0000gn/T/ibax-temp" 61 | FirstBlockPath = "/ibax-data/1block" 62 | TLS = false 63 | TLSCert = "" 64 | TLSKey = "" 65 | OBSMode = "none" 66 | HTTPServerMaxBodySize = 1048576 67 | MaxPageGenerationTime = 3000 68 | NodesAddr = [] 69 | 70 | [TCPServer] 71 | Host = "127.0.0.1" 72 | Port = 7078 73 | 74 | [HTTP] 75 | Host = "127.0.0.1" 76 | Port = 7079 77 | 78 | [DB] 79 | Name = "ibax" 80 | Host = "127.0.0.1" 81 | Port = 5432 82 | User = "postgres" 83 | Password = "123456" 84 | LockTimeout = 5000 85 | 86 | [StatsD] 87 | Host = "127.0.0.1" 88 | Port = 8125 89 | Name = "ibax" 90 | 91 | [Centrifugo] 92 | Secret = "127.0.0.1" 93 | URL = "127.0.0.1" 94 | 95 | [Log] 96 | LogTo = "stdout" 97 | LogLevel = "ERROR" 98 | LogFormat = "text" 99 | [Log.Syslog] 100 | Facility = "kern" 101 | Tag = "go-ibax" 102 | 103 | [TokenMovement] 104 | Host = "" 105 | Port = 0 106 | Username = "" 107 | Password = "" 108 | To = "" 109 | From = "" 110 | Subject = "" 111 | ``` 112 | -------------------------------------------------------------------------------- /docs/zh-CN/reference/desync_monitor.md: -------------------------------------------------------------------------------- 1 | # 同步监控工具 {#synchronized-monitoring-tool} 2 | 3 | Desync_monitor是一种特殊工具，可用于验证指定节点上的数据库是否已同步。 4 | 5 | 该工具可以作为守护进程使用，也可以启动以执行一次性检查。 6 | 7 | 该工具的操作原理基于以下内容： 8 | 9 | > 1. 每个区块包含所有交易的所有更改的哈希，请求指定的节点提供其最后一个区块ID； 10 | > 2. 然后从所有节点请求具有该ID的区块，并比较上述哈希； 11 | > 3. 如果哈希不同，会将同步错误消息发送到命令中指定的电子邮件地址。 12 | 13 | ## 位置 {#location} 14 | 15 | 该工具位于 `tools/desync_monitor/`。 16 | 17 | ## 命令提示标志 {#command-prompt-flags} 18 | 19 | 可以从命令提示符使用以下标志： 20 | 21 | > - **confPath** -- 配置文件的路径。默认文件名为 `config.toml`； 22 | > - **nodesList** -- 请求区块的节点列表，以逗号分隔。默认为`127.0.0.1:7079`； 23 | > - **daemonMode** -- 作为守护进程启动，应该在每N秒需要验证的情况下使用。该标志默认设置为 `false`； 24 | > - **queryingPeriod** -- 如果工具作为守护进程启动，该参数设置检查之间的时间间隔(以秒为单位)。默认为 `1` 秒。 25 | 26 | - **alertMessageTo** -- 将向其发送同步警告错误的电子邮件地址。 27 | 28 | > - **alertMessageSubj** -- 在警告消息中的消息主题，默认为节点同步问题； 29 | > - **alertMessageFrom** -- 发送消息的地址。 30 | > - **smtpHost** -- SMTP服务器主机，用于发送电子邮件，默认为`""`； 31 | > - **smtpPort** -- SMTP服务器端口，用于发送电子邮件消息，默认为`25`； 32 | > - **smtpUsername** -- SMTP服务器用户名，默认为 `""`； 33 | > - **smtpPassword** -- SMTP服务器密码，默认为 `""`。 34 | 35 | ## 配置 {#configuration} 36 | 37 | 该工具使用toml格式的配置文件。 38 | 39 | 默认情况下，它会在启动二进制文件的文件夹中查找 *config.toml* 文件。 40 | 41 | 可以使用 **configPath** 标志更改文件路径。 42 | 43 | ```text 44 | nodes_list = ["http://127.0.0.1:7079", "http://127.0.0.1:7002"] 45 | 46 | [daemon] 47 | daemon = false 48 | querying_period = 1 49 | 50 | [alert_message] 51 | to = "" 52 | subject = "problem with xxx nodes" 53 | from = "" 54 | 55 | [smtp] 56 | host = "" 57 | port = 25 58 | username = "" 59 | password = "" 60 | ``` 61 | 62 | ### nodes_list {#nodes-list} 63 | 64 | > - **nodes_list** -- 请求信息的节点（主机）列表。 65 | 66 | ### [daemon] {#daemon} 67 | 68 | 守护进程模式配置。 69 | 70 | > - **daemon_mode** -- 工具作为守护进程工作并执行同步检查。 71 | > - **querying_period** -- 同步检查之间的时间间隔。 72 | 73 | ### [alert_message] {#alert-message} 74 | 75 | 警告消息参数。 76 | 77 | > - **to** -- 同步错误警告消息的收件地址； 78 | > - **subject** -- 消息主题； 79 | > - **from** -- 发件地址。 80 | 81 | ### [smtp] {#smtp} 82 | 83 | 简单邮件传输协议 (Simple Mail Transfer Protocol, SMTP) 服务器的参数，用于发送同步错误消息。 84 | 85 | > - **host** -- SMTP服务器主机； 86 | > - **port** --SMTP服务器端口； 87 | > - **username** -- SMTP服务器用户名； 88 | > - **password** --SMTP服务器密码； 89 | -------------------------------------------------------------------------------- /docs/zh-CN/topics/daemons.md: -------------------------------------------------------------------------------- 1 | # 守护进程 {#daemon} 2 | 3 | 该章节介绍 IBAX区块链平台 节点如何从技术角度相互交互。 4 | 5 | ## 关于服务端守护进程 {#about-the-server-daemon} 6 | 7 | 它需在每个网络节点上运行。服务端守护进程执行服务端各个功能并支持IBAX区块链平台的区块链协议。守护进程在区块链网络中分发区块和交易、生成新区块、验证接收到的区块和交易。守护进程可以防止区块链分叉问题。 8 | 9 | ### 荣誉节点守护进程 {#honor-node-daemon} 10 | 11 | 荣誉节点 运行以下服务端守护进程： 12 | 13 | > - [BlockGenerator守护进程](#blockgenerator-daemon) 14 | > 15 | > > 生成新区块。 16 | > 17 | > - [BlockCollection守护进程](#blockcollection-daemon) 18 | > 19 | > > 从其他节点下载新区块。 20 | > 21 | > - [Confirmations守护进程](#confirmations-daemon) 22 | > 23 | > > 确认节点上存在的区块也存在于大多数其他节点上。 24 | > 25 | > - [Disseminator守护进程](#disseminator-daemon) 26 | > 27 | > > 将交易和区块分发给其他主节点。 28 | > 29 | > - QueueParserBlocks 守护进程 30 | > 31 | > > 处理区块队列中的区块，区块队列包含来自其他节点的区块。 32 | > > 33 | > > 区块处理逻辑和 [BlockCollection守护进程](#blockcollection-daemon) 相同。 34 | > 35 | > - QueueParserTx 守护进程 36 | > 37 | > > 验证交易队列中的交易。 38 | > 39 | > - Scheduler 守护进程 40 | > 41 | > > 按任务计划运行合约。 42 | 43 | ### 守护节点 守护进程 {#guardian-node-daemon} 44 | 45 | 守护节点 运行以下服务端守护进程： 46 | 47 | > - [BlockCollection守护进程](#blockcollection-daemon) 48 | > - [Confirmations守护进程](#confirmations-daemon) 49 | > - [Disseminator守护进程](#disseminator-daemon) 50 | > - QueueParserTx 51 | > - Scheduler 52 | 53 | ## BlockCollection守护进程 {#blockcollection-daemon} 54 | 55 | BlocksCollection守护进程下载区块并将区块链与其他网络节点同步。 56 | 57 | ### 区块链同步 {#blockchain-synchronization} 58 | 59 | BlocksCollection守护进程通过确定区块链网络中的最大区块高度，请求新区块以及解决区块链中的分叉来同步区块链。 60 | 61 | #### 区块链更新检查 {#check-for-blockchain-updates} 62 | 63 | BlocksCollection守护进程将当前区块ID的请求发送到所有 荣誉节点。 64 | 65 | 如果该守护进程的节点的当前区块ID小于任何 荣誉节点的当前区块ID，则该区块链网络节点被认为是过时的。 66 | 67 | #### 下载新区块 {#download-new-blocks} 68 | 69 | 返回最大当前区块高度的节点被视为最新节点。 70 | 71 | 该守护进程下载所有尚未知道的区块。 72 | 73 | #### 解决分叉 {#solving-the-fork-issue} 74 | 75 | 如果在区块链中检测到分叉，则该守护进程通过将所有区块下载到共同的父区块来向后移动分叉。 76 | 77 | 找到共同的父区块后，将在该守护进程的节点区块链上执行回滚，并将正确的区块添加到区块链中，直到最新的区块。 78 | 79 | ### 数据表 {#tables-1} 80 | 81 | 82 | BlocksCollection守护进程使用以下数据表： 83 | 84 | > - block_chain 85 | > - transactions 86 | > - transactions_status 87 | > - info_block 88 | 89 | ### 请求 {#request-1} 90 | 91 | BlockCollection守护程序向其他守护程序发出以下请求： 92 | 93 | > - [Type 10](#type-10)指向所有 **荣誉节点** 中最大的区块ID。 94 | > - [Type 7](#type-7)指向最大区块ID的数据。 95 | 96 | ## BlockGenerator守护进程 {#blockgenerator-daemon} 97 | 98 | BlockGenerator守护进程生成新区块。 99 | 100 | ### 预验证 {#pre-verification} 101 | 102 | BlockGenerator守护进程通过分析区块链中的最新区块来计划新的区块生成。 103 | 104 | 如果满足以下条件，则可以生成新区块： 105 | 106 | > - 生成最新区块的节点位于荣誉节点列表中守护进程节点。 107 | > - 自最新未验证区块生成以来经过的最短时间。 108 | 109 | ### 区块生成 {#block-generation} 110 | 111 | 该守护进程生成新区块后，新区块包含所有新交易。这些交易可以从其他节点的[Disseminator守护进程](#disseminator-daemon)接收，也可以由该守护进程的节点生成。生成的区块保存在该节点数据库中。 112 | 113 | ### 数据表 {#tables-2} 114 | 115 | BlockGenerator守护程序使用以下表： 116 | 117 | > - block_chain (saves new blocks) 118 | > - transactions 119 | > - transactions_status 120 | > - info_block 121 | 122 | ### 请求 {#request-2} 123 | 124 | BlockGenerator守护进程不向其他守护进程发出任何请求。 125 | 126 | ## Disseminator守护进程 {#disseminator-daemon} 127 | 128 | Disseminator守护进程将交易和区块发送到所有 荣誉节点。 129 | 130 | ### 守护节点 {#guardian-node} 131 | 132 | 在 守护节点 上工作时，守护进程将其节点生成的交易发送到所有 荣誉节点。 133 | 134 | ### 荣誉节点 {#honor-node} 135 | 136 | 在荣誉节点上工作时，守护进程会将生成的区块和交易的哈希值发送到所有荣誉节点。 137 | 138 | 然后，荣誉节点响应其节点未知的交易请求。守护进程发送完整的交易数据作为响应。 139 | 140 | ### 数据表 {#tables-3} 141 | 142 | Disseminator守护进程使用以下表： 143 | 144 | > - transactions 145 | 146 | ### 请求 {#request-3} 147 | 148 | Disseminator守护进程向其他守护进程发出以下请求： 149 | 150 | > - [Type 1](#type-1) 向 荣誉节点发送交易和区块哈希。 151 | > - [Type 2](#type-2) 从 荣誉节点接收交易数据。 152 | 153 | ## Confirmations守护进程 {#confirmations-daemon} 154 | 155 | Confirmations守护进程检查其节点中的所有区块是否存在于大多数其他节点上。 156 | 157 | ### 区块确认 {#block-confirmation} 158 | 159 | 当网络中的多个节点已确认区块时，将认为该区块已被确认。 160 | 161 | 该守护进程从数据库中当前未确认的第一个区块开始逐个确认所有区块。 162 | 163 | 每个区块都以这种方式确认： 164 | 165 | > - 向所有荣誉节点发送请求，该请求包含了正在确认的区块ID。 166 | > - 所有荣誉节点对该区块的哈希进行响应。 167 | > - 如果响应的哈希值与守护进程节点上的区块的哈希值匹配，则会增加确认计数器。如果哈希不匹配，取消确认计数器将增加。 168 | 169 | ### 数据表 {#tables-4} 170 | 171 | Confirmations守护进程使用以下数据表： 172 | 173 | > - confirmation 174 | > - info_block 175 | 176 | ### 请求 {#request-4} 177 | 178 | Confirmations守护进程向其他守护进程发出以下请求： 179 | 180 | > - [Type 4](#type-4) 向荣誉节点请求区块哈希。 181 | 182 | ## TCP服务协议 {#tcp-service-protocol} 183 | 184 | TCP服务协议在 荣誉节点和全节点上工作，TCP服务协议使用TCP上的二进制协议来处理来自BlocksCollection、Disseminator和Confirmation守护进程的请求。 185 | 186 | ## 请求类型 {#request-type} 187 | 188 | 每个请求都有一个由请求的前两个字节定义的类型。 189 | 190 | ### Type 1 {#type-1} 191 | 192 | #### 请求发送者 {#request-sender-1} 193 | 194 | [Disseminator守护进程](#disseminator-daemon) 发送该请求。 195 | 196 | #### 请求数据 {#request-data-1} 197 | 198 | 交易和区块哈希。 199 | 200 | #### 请求处理 {#request-processing-1} 201 | 202 | 区块哈希被添加到区块队列中。 203 | 204 | 对交易哈希进行解析验证，并选择节点上尚未出现的交易。 205 | 206 | #### 响应 {#response-1} 207 | 208 | 无。处理该请求后会发出 [Type 2](#type-2) 请求。 209 | 210 | ### Type 2 {#type-2} 211 | 212 | #### 请求发送者 {#request-sender-2} 213 | 214 | [Disseminator守护进程](#disseminator-daemon) 发送该请求。 215 | 216 | #### 请求数据 {#request-data-2} 217 | 218 | 交易数据，包括数据大小： 219 | 220 | > - *data_size* (4个字节) 221 | > 222 | > > 交易数据的大小，以字节为单位。 223 | > 224 | > - *data* (data_size个字节) 225 | > 226 | > > 交易数据。 227 | 228 | #### 请求处理 {#request-processing-2} 229 | 230 | 验证交易并将其添加到交易队列中。 231 | 232 | #### 响应 {#response-2} 233 | 234 | 无。 235 | 236 | ### Type 4 {#type-4} 237 | 238 | #### 请求发送者 {#request-sender-3} 239 | 240 | [Confirmations守护进程](#confirmations-daemon) 发送该请求。 241 | 242 | #### 请求数据 {#request-data-3} 243 | 244 | 区块ID。 245 | 246 | #### 响应 {#response-3} 247 | 248 | 区块哈希。 249 | 250 | 如果不存在该ID的区块，则返回 `0`。 251 | 252 | ### Type 7 {#type-7} 253 | 254 | #### 请求发送者 {#request-sender-4} 255 | 256 | [BlockCollection守护进程](#blockcollection-daemon) 发送该请求。 257 | 258 | #### 请求数据 {#request-data-4} 259 | 260 | 区块ID。 261 | 262 | > - *block_id* (4个字节) 263 | 264 | #### 响应 {#response-4} 265 | 266 | 区块数据，包括数据大小。 267 | 268 | > - *data_size* (4个字节) 269 | > 270 | > > 区块数据的大小，以字节为单位。 271 | > 272 | > - *data* (data_size个字节) 273 | > 274 | > > 区块数据。 275 | 276 | 如果不存在该ID的区块，则关闭连接。 277 | 278 | ### Type 10 {#type-10} 279 | 280 | #### 请求发送者 {#request-sender-5} 281 | 282 | [BlockCollection守护进程](#blockcollection-daemon) 发送该请求。 283 | 284 | #### 请求数据 {#request-data-5} 285 | 286 | 无 287 | 288 | #### 响应 {#response-5} 289 | 290 | 区块ID。 291 | 292 | > - *block_id* (4个字节) 293 | -------------------------------------------------------------------------------- /markdown_fix_link_anchor.py: -------------------------------------------------------------------------------- 1 | import os 2 | import re 3 | 4 | 5 | def fix_link(file_path): 6 | with open(file_path, mode='r', encoding='utf-8', errors='replace') as f: 7 | html = f.read() 8 | regex_link_anchor = re.compile(' ({#(.+?)})[<"]', re.I | re.M | re.S) 9 | link_anchor = regex_link_anchor.findall(html) 10 | # print(link_anchor) 11 | flag = False 12 | for link_text in link_anchor: 13 | anchor = link_text[0] 14 | html = html.replace(anchor, '') 15 | flag = True 16 | 17 | if flag: 18 | # print(link_anchor) 19 | # print(f'Fix: {file_path}') 20 | with open(file_path, 'w', encoding='utf-8', errors='replace') as f1: 21 | f1.write(html) 22 | 23 | 24 | if __name__ == '__main__': 25 | 26 | for root, dirs, files in os.walk(r"ibax-io.github.io"): 27 | for file in files: 28 | if file.endswith(".html") or file.endswith(".js"): 29 | path_html = os.path.join(root, file) 30 | fix_link(path_html) 31 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "devDependencies": { 3 | "vuepress": "^1.9.9" 4 | }, 5 | "scripts": { 6 | "dev": "vuepress dev docs", 7 | "build": "vuepress build docs" 8 | }, 9 | "name": "IBAX-Documentation", 10 | "version": "1.0.0", 11 | "main": "index.js", 12 | "license": "MIT" 13 | } 14 | -------------------------------------------------------------------------------- /syncDist.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | WORKDIR=ibax-io.github.io 4 | distDir=docs/.vuepress/dist/ 5 | fixLinkPy=markdown_fix_link_anchor.py 6 | if [ ! -d $WORKDIR ]; then 7 | echo "dist github dir does not exit,please clone" 8 | exit 9 | else 10 | if [ -d $distDir ];then 11 | cd $WORKDIR 12 | find ./ | grep -v .git | xargs rm -rf {} 13 | echo "docs.ibax.io" > CNAME 14 | cp -rf ../$distDir* . 15 | cd - 16 | if [ -f $fixLinkPy ];then 17 | python $fixLinkPy 18 | else 19 | echo "fix link python file does not exit!" 20 | fi 21 | else 22 | echo "dist dir does not exit,please yarn build" 23 | exit 24 | fi 25 | fi 26 | --------------------------------------------------------------------------------