diff --git a/i18n/ja/code.json b/i18n/ja/code.json index faa3f627d92b..6334940cc4ad 100644 --- a/i18n/ja/code.json +++ b/i18n/ja/code.json @@ -3,144 +3,144 @@ "message": "{title}" }, "{tagline}": { - "message": "{tagline}" + "message": "{tagline}ytn" }, "Getting Started": { - "message": "Getting Started" + "message": "はじめに" }, "Node Operators": { - "message": "Node Operators" + "message": "ノード演算子" }, "API references": { - "message": "API references" + "message": "APIリファレンス" }, "APIs and libraries": { - "message": "APIs and libraries" + "message": "APIとライブラリ" }, "Got a question? Visit our forum!": { - "message": "Got a question? Visit our forum!" + "message": "ご質問ですか？フォーラムをご覧ください！" }, "theme.ErrorPageContent.title": { - "message": "This page crashed.", + "message": "このページはクラッシュした。", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { - "message": "Scroll back to top", + "message": "トップに戻る", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { - "message": "Archive", + "message": "アーカイブ", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { - "message": "Archive", + "message": "アーカイブ", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { - "message": "Blog list page navigation", + "message": "ブログ一覧ページナビゲーション", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { - "message": "Newer Entries", + "message": "新しいエントリー", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { - "message": "Older Entries", + "message": "古いエントリー", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.plurals": { - "message": "One post|{count} posts", + "message": "1件の投稿|{count} 投稿", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { - "message": "{nPosts} tagged with \"{tagName}\"", + "message": "{nPosts} タグ \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.tags.tagsPageLink": { - "message": "View All Tags", + "message": "すべてのタグを見る", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel": { - "message": "Switch between dark and light mode (currently {mode})", + "message": "ダークモードとライトモードの切り替え（現在は {mode}）", "description": "The ARIA label for the navbar color mode toggle" }, "theme.colorToggle.ariaLabel.mode.dark": { - "message": "dark mode", + "message": "ダークモード", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel.mode.light": { - "message": "light mode", + "message": "ライトモード", "description": "The name for the light color mode" }, "theme.blog.post.paginator.navAriaLabel": { - "message": "Blog post page navigation", + "message": "ブログ記事ページナビゲーション", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { - "message": "Newer Post", + "message": "新しい投稿", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { - "message": "Older Post", + "message": "古い投稿", "description": "The blog post button label to navigate to the older/next post" }, "theme.docs.breadcrumbs.navAriaLabel": { - "message": "Breadcrumbs", + "message": "パン粉", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription": { - "message": "{count} items", + "message": "{count} 項目", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { - "message": "Docs pages", + "message": "ドキュメントページ", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { - "message": "Previous", + "message": "前へ", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { - "message": "Next", + "message": "次のページ", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { - "message": "One doc tagged|{count} docs tagged", + "message": "タグ付けされた1つの文書|{count} タグ付けされた文書", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { - "message": "{nDocsTagged} with \"{tagName}\"", + "message": "{nDocsTagged}{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { - "message": "Version: {versionLabel}" + "message": "バージョン： {versionLabel}" }, "theme.docs.versions.unreleasedVersionLabel": { - "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", + "message": "これは {siteTitle} {versionLabel} バージョンの未公開ドキュメントです。", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { - "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", + "message": "これは {siteTitle} {versionLabel}のドキュメントであり、現在はメンテナンスされていない。", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { - "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", + "message": "最新のドキュメントについては、 {latestVersionLink} ({versionLabel}) を参照してください。", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { - "message": "latest version", + "message": "最新版", "description": "The label used for the latest version suggestion link label" }, "theme.common.editThisPage": { - "message": "Edit this page", + "message": "このページを編集する", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { - "message": "Direct link to {heading}", + "message": "{heading}への直接リンク", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { - "message": " on {date}", + "message": " {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { @@ -148,335 +148,335 @@ "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { - "message": "Last updated{atDate}{byUser}", + "message": "最終更新{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.navbar.mobileVersionsDropdown.label": { - "message": "Versions", + "message": "バージョン", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.NotFound.title": { - "message": "Page Not Found", + "message": "ページが見つかりません", "description": "The title of the 404 page" }, "theme.tags.tagsListLabel": { - "message": "Tags:", + "message": "タグ", "description": "The label alongside a tag list" }, "theme.admonition.caution": { - "message": "caution", + "message": "注意", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { - "message": "danger", + "message": "危険", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { - "message": "info", + "message": "インフォメーション", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { - "message": "note", + "message": "備考", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { - "message": "tip", + "message": "チップ", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { - "message": "warning", + "message": "警告", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.AnnouncementBar.closeButtonAriaLabel": { - "message": "Close", + "message": "閉じる", "description": "The ARIA label for close button of announcement bar" }, "theme.blog.sidebar.navAriaLabel": { - "message": "Blog recent posts navigation", + "message": "ブログ最新記事ナビゲーション", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.CodeBlock.copied": { - "message": "Copied", + "message": "コピー", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { - "message": "Copy code to clipboard", + "message": "コードをクリップボードにコピーする", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.copy": { - "message": "Copy", + "message": "コピー", "description": "The copy button label on code blocks" }, "theme.CodeBlock.wordWrapToggle": { - "message": "Toggle word wrap", + "message": "ワードラップの切り替え", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { - "message": "Expand sidebar category '{label}'", + "message": "サイドバーのカテゴリーを拡大する '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { - "message": "Collapse sidebar category '{label}'", + "message": "サイドバーカテゴリーの折りたたみ '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.NavBar.navAriaLabel": { - "message": "Main", + "message": "メイン", "description": "The ARIA label for the main navigation" }, "theme.navbar.mobileLanguageDropdown.label": { - "message": "Languages", + "message": "言語", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { - "message": "On this page", + "message": "このページでは", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { - "message": "Read More", + "message": "続きを読む", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { - "message": "Read more about {title}", + "message": "{title}についてもっと読む", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.NotFound.p1": { - "message": "We could not find what you were looking for.", + "message": "お探しのものは見つかりませんでした。", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { - "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", + "message": "リンク元のサイトのオーナーに連絡し、リンク切れを伝えてください。", "description": "The 2nd paragraph of the 404 page" }, "theme.docs.breadcrumbs.home": { - "message": "Home page", + "message": "ホームページ", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.collapseButtonTitle": { - "message": "Collapse sidebar", + "message": "サイドバーの折りたたみ", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { - "message": "Collapse sidebar", + "message": "サイドバーの折りたたみ", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { - "message": "Close navigation bar", + "message": "ナビゲーションバーを閉じる", "description": "The ARIA label for close button of mobile sidebar" }, "theme.blog.post.readingTime.plurals": { - "message": "One min read|{readingTime} min read", + "message": "1分で読める|{readingTime} min read", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.sidebar.navAriaLabel": { - "message": "Docs sidebar", + "message": "ドキュメント・サイドバー", "description": "The ARIA label for the sidebar navigation" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { - "message": "← Back to main menu", + "message": "← メインメニューに戻る", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { - "message": "Toggle navigation bar", + "message": "トグルナビゲーションバー", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.docs.sidebar.expandButtonTitle": { - "message": "Expand sidebar", + "message": "サイドバーを拡大する", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { - "message": "Expand sidebar", + "message": "サイドバーを拡大する", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.SearchBar.seeAll": { - "message": "See all {count} results" + "message": "すべての {count} の結果を見る" }, "theme.SearchPage.documentsFound.plurals": { - "message": "One document found|{count} documents found", + "message": "文書が1件見つかりました|{count} 文書が見つかりました", "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.SearchPage.existingResultsTitle": { - "message": "Search results for \"{query}\"", + "message": "の検索結果 \"{query}\"", "description": "The search page title for non-empty query" }, "theme.SearchPage.emptyResultsTitle": { - "message": "Search the documentation", + "message": "ドキュメントを検索する", "description": "The search page title for empty query" }, "theme.SearchPage.inputPlaceholder": { - "message": "Type your search here", + "message": "ここに検索結果を入力", "description": "The placeholder for search page input" }, "theme.SearchPage.inputLabel": { - "message": "Search", + "message": "検索", "description": "The ARIA label for search page input" }, "theme.SearchPage.algoliaLabel": { - "message": "Search by Algolia", + "message": "アルゴリアで検索", "description": "The ARIA label for Algolia mention" }, "theme.SearchPage.noResultsText": { - "message": "No results were found", + "message": "結果は見つかりませんでした", "description": "The paragraph for empty search result" }, "theme.SearchPage.fetchingNewResults": { - "message": "Fetching new results...", + "message": "新しい結果を取得...", "description": "The paragraph for fetching new search results" }, "theme.SearchBar.label": { - "message": "Search", + "message": "検索", "description": "The ARIA label and placeholder for search button" }, "theme.SearchModal.searchBox.resetButtonTitle": { - "message": "Clear the query", + "message": "クエリをクリアする", "description": "The label and ARIA label for search box reset button" }, "theme.SearchModal.searchBox.cancelButtonText": { - "message": "Cancel", + "message": "キャンセル", "description": "The label and ARIA label for search box cancel button" }, "theme.SearchModal.startScreen.recentSearchesTitle": { - "message": "Recent", + "message": "最近", "description": "The title for recent searches" }, "theme.SearchModal.startScreen.noRecentSearchesText": { - "message": "No recent searches", + "message": "最近の検索なし", "description": "The text when no recent searches" }, "theme.SearchModal.startScreen.saveRecentSearchButtonTitle": { - "message": "Save this search", + "message": "この検索を保存", "description": "The label for save recent search button" }, "theme.SearchModal.startScreen.removeRecentSearchButtonTitle": { - "message": "Remove this search from history", + "message": "この検索を履歴から削除する", "description": "The label for remove recent search button" }, "theme.SearchModal.startScreen.favoriteSearchesTitle": { - "message": "Favorite", + "message": "お気に入り", "description": "The title for favorite searches" }, "theme.SearchModal.startScreen.removeFavoriteSearchButtonTitle": { - "message": "Remove this search from favorites", + "message": "この検索をお気に入りから削除する", "description": "The label for remove favorite search button" }, "theme.SearchModal.errorScreen.titleText": { - "message": "Unable to fetch results", + "message": "結果を取得できない", "description": "The title for error screen of search modal" }, "theme.SearchModal.errorScreen.helpText": { - "message": "You might want to check your network connection.", + "message": "ネットワーク接続を確認したほうがいいかもしれない。", "description": "The help text for error screen of search modal" }, "theme.SearchModal.footer.selectText": { - "message": "to select", + "message": "を選択します。", "description": "The explanatory text of the action for the enter key" }, "theme.SearchModal.footer.selectKeyAriaLabel": { - "message": "Enter key", + "message": "エンターキー", "description": "The ARIA label for the Enter key button that makes the selection" }, "theme.SearchModal.footer.navigateText": { - "message": "to navigate", + "message": "ナビゲートする", "description": "The explanatory text of the action for the Arrow up and Arrow down key" }, "theme.SearchModal.footer.navigateUpKeyAriaLabel": { - "message": "Arrow up", + "message": "矢印を上に", "description": "The ARIA label for the Arrow up key button that makes the navigation" }, "theme.SearchModal.footer.navigateDownKeyAriaLabel": { - "message": "Arrow down", + "message": "矢印を下に", "description": "The ARIA label for the Arrow down key button that makes the navigation" }, "theme.SearchModal.footer.closeText": { - "message": "to close", + "message": "閉じる", "description": "The explanatory text of the action for Escape key" }, "theme.SearchModal.footer.closeKeyAriaLabel": { - "message": "Escape key", + "message": "エスケープキー", "description": "The ARIA label for the Escape key button that close the modal" }, "theme.SearchModal.footer.searchByText": { - "message": "Search by", + "message": "で検索", "description": "The text explain that the search is making by Algolia" }, "theme.SearchModal.noResultsScreen.noResultsText": { - "message": "No results for", + "message": "該当事項はありません。", "description": "The text explains that there are no results for the following search" }, "theme.SearchModal.noResultsScreen.suggestedQueryText": { - "message": "Try searching for", + "message": "を検索してみよう。", "description": "The text for the suggested query when no results are found for the following search" }, "theme.SearchModal.noResultsScreen.reportMissingResultsText": { - "message": "Believe this query should return results?", + "message": "このクエリーは結果を返すべきだと思いますか？", "description": "The text for the question where the user thinks there are missing results" }, "theme.SearchModal.noResultsScreen.reportMissingResultsLinkText": { - "message": "Let us know.", + "message": "教えてください。", "description": "The text for the link to report missing results" }, "theme.SearchModal.placeholder": { - "message": "Search docs", + "message": "ドキュメント検索", "description": "The placeholder of the input of the DocSearch pop-up modal" }, "theme.CodeBlock.expanded": { - "message": "Expanded", + "message": "拡大", "description": "The expanded button label on code blocks" }, "theme.CodeBlock.expandButtonAriaLabel": { - "message": "Expand code to fullscreen", + "message": "コードをフルスクリーンに拡大", "description": "The ARIA label for expand code blocks button" }, "theme.CodeBlock.expand": { - "message": "Expand", + "message": "拡大する", "description": "The expand button label on code blocks" }, "theme.CodeBlock.exitButtonAriaLabel": { - "message": "Exit expanded view", + "message": "拡大表示を終了する", "description": "The ARIA label for exit expanded view button" }, "theme.ErrorPageContent.tryAgain": { - "message": "Try again", + "message": "再試行", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { - "message": "Skip to main content", + "message": "本文へスキップ", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { - "message": "Tags", + "message": "タグ", "description": "The title of the tag list page" }, "theme.unlistedContent.title": { - "message": "Unlisted page", + "message": "未掲載ページ", "description": "The unlisted content banner title" }, "theme.unlistedContent.message": { - "message": "This page is unlisted. Search engines will not index it, and only users having a direct link can access it.", + "message": "このページは未掲載です。検索エンジンにインデックスされず、直接リンクを持つユーザーだけがアクセスできます。", "description": "The unlisted content banner message" }, "Kaia Overview": { - "message": "Kaia Overview" + "message": "カイアの概要" }, "Want to know about Kaia?": { - "message": "Want to know about Kaia?" + "message": "カイアについて知りたい？" }, "Want to start building on Kaia?": { - "message": "Want to start building on Kaia?" + "message": "カイアで建築を始めたい？" }, "Instructions on running Kaia's nodes": { - "message": "Instructions on running Kaia's nodes" + "message": "カイアのノードの動かし方" }, "Kaia Developer Hub": { - "message": "Kaia Developer Hub" + "message": "カイア開発者ハブ" }, "Kaia's Developer portal": { - "message": "Kaia's Developer portal" + "message": "カイアの開発者ポータル" }, "Kaia Developer Forum": { - "message": "Kaia Developer Forum" + "message": "カイア開発者フォーラム" }, "theme.docs.DocCard.categoryDescription.plurals": { - "message": "{count} items", + "message": "{count} 項目", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.blog.author.pageTitle": { @@ -484,149 +484,153 @@ "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { - "message": "Authors", + "message": "著者紹介", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { - "message": "View all authors", + "message": "すべての著者を表示", "description": "The label of the link targeting the blog authors page" }, "theme.contentVisibility.unlistedBanner.title": { - "message": "Unlisted page", + "message": "未掲載ページ", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { - "message": "This page is unlisted. Search engines will not index it, and only users having a direct link can access it.", + "message": "このページは未掲載です。検索エンジンにインデックスされず、直接リンクを持つユーザーだけがアクセスできます。", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { - "message": "Draft page", + "message": "草案ページ", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { - "message": "This page is a draft. It will only be visible in dev and be excluded from the production build.", + "message": "このページはドラフトです。本番ビルドからは除外されます。", "description": "The draft content banner message" }, "disclaimer.message": { - "message": "This page uses machine translation from English, which may contain errors or unclear language. For the most accurate information, please see the original English version. Some content may be in the original English due to frequent updates. Help us improve this page's translation by joining our effort on Crowdin.", + "message": "このページは英語からの機械翻訳を使用しており、誤りや不明瞭な表現が含まれている可能性があります。最も正確な情報については、オリジナルの英語版をご覧ください。頻繁な更新のため、一部のコンテンツはオリジナルの英語になっている可能性があります。Crowdinでの取り組みに参加して、このページの翻訳改善にご協力ください。", "description": "Machine translation disclaimer for non-English documentation pages" }, "JSON-RPC API Reference": { - "message": "JSON-RPC API Reference" + "message": "JSON-RPC APIリファレンス" }, "Discover and Engage with Kaia's JSON-RPC APIs": { - "message": "Discover and Engage with Kaia's JSON-RPC APIs" + "message": "カイアのJSON-RPC APIを発見し、活用する" }, "Unlock Kaia's full potential with our interactive API documentation. Test API calls directly in the docs, explore detailed request and response examples, and generate code snippets in curl, Python, Node.js, and Java. Whether developing new applications or integrating with existing systems, our comprehensive API reference provides the tools for efficient development on the Kaia platform.": { - "message": "Unlock Kaia's full potential with our interactive API documentation. Test API calls directly in the docs, explore detailed request and response examples, and generate code snippets in curl, Python, Node.js, and Java. Whether developing new applications or integrating with existing systems, our comprehensive API reference provides the tools for efficient development on the Kaia platform." + "message": "インタラクティブなAPIドキュメントでKaiaの可能性を最大限に引き出してください。ドキュメントで直接APIコールをテストし、詳細なリクエストとレスポンスの例を調べ、curl、Python、Node.js、Javaでコードスニペットを生成します。新しいアプリケーションの開発であれ、既存のシステムとの統合であれ、私たちの包括的なAPIリファレンスは、カイアプラットフォーム上での効率的な開発のためのツールを提供します。" }, "Get started with Kaia's JSON RPC APIs": { - "message": "Get started with Kaia's JSON RPC APIs" + "message": "カイアのJSON RPC APIを使い始める" }, "homepage.favorites.gettingStarted.title": { - "message": "Getting Started", + "message": "はじめに", "description": "Title for Getting Started guide" }, "homepage.favorites.gettingStarted.description": { - "message": "Deploy your first smart contract using Hardhat.", + "message": "Hardhatを使って最初のスマート・コントラクトをデプロイする。", "description": "Description for Getting Started guide" }, "homepage.favorites.metamask.title": { - "message": "MetaMask Guide", + "message": "メタマスク・ガイド", "description": "Title for MetaMask guide" }, "homepage.favorites.metamask.description": { - "message": "Connect MetaMask to Kaia.", + "message": "メタマスクをカイアに接続する。", "description": "Description for MetaMask guide" }, "homepage.favorites.snapshot.title": { - "message": "Node Snapshot Guide", + "message": "ノード・スナップショット・ガイド", "description": "Title for Node Snapshot guide" }, "homepage.favorites.snapshot.description": { - "message": "Use Chaindata Snapshots.", + "message": "Chaindata Snapshotsを使用してください。", "description": "Description for Node Snapshot guide" }, "homepage.favorites.rpc.title": { - "message": "Public JSON RPC Endpoints", + "message": "パブリックJSON RPCエンドポイント", "description": "Title for Public JSON RPC Endpoints" }, "homepage.favorites.rpc.description": { - "message": "Build and test your products without running your own node.", + "message": "自前のノードを運用することなく、製品を構築し、テストすることができます。", "description": "Description for Public JSON RPC Endpoints" }, "homepage.favorites.wallets.title": { - "message": "Wallets", + "message": "財布", "description": "Title for Wallets section" }, "homepage.favorites.wallets.description": { - "message": "Integrate and secure digital assets seamlessly.", + "message": "デジタル資産をシームレスに統合し、保護する。", "description": "Description for Wallets section" }, "homepage.favorites.indexers.title": { - "message": "Indexers", + "message": "インデクサ", "description": "Title for Indexers section" }, "homepage.favorites.indexers.description": { - "message": "Query and index blockchain data for efficient dApp performance.", + "message": "効率的なdAppのパフォーマンスを実現するために、ブロックチェーンのデータを照会し、インデックスを作成します。", "description": "Description for Indexers section" }, "homepage.favorites.guides.title": { - "message": "Popular Guides", + "message": "人気ガイド", "description": "Title for the Popular Guides section" }, "homepage.favorites.guides.viewMore": { - "message": "View More Guides", + "message": "その他のガイドを見る", "description": "Link text to view more guides" }, "homepage.favorites.resources.title": { - "message": "Popular Resources", + "message": "人気のリソース", "description": "Title for the Popular Resources section" }, "homepage.favorites.resources.viewMore": { - "message": "View More Resources", + "message": "その他のリソースを見る", "description": "Link text to view more resources" }, "DApp Developers": { - "message": "DApp Developers" + "message": "アプリ開発者" }, "API References": { - "message": "API References" + "message": "APIリファレンス" }, "homepage.sdk.ethersjs.name": { - "message": "Ethers.js Extension", + "message": "Ethers.jsエクステンション", "description": "Name of the Ethers.js Extension SDK" }, "homepage.sdk.web3js.name": { - "message": "Web3.js Extension", + "message": "Web3.jsエクステンション", "description": "Name of the Web3.js Extension SDK" }, "homepage.sdk.web3j.name": { - "message": "Web3j Extension", + "message": "Web3jエクステンション", "description": "Name of the Web3j Extension SDK" }, "homepage.sdk.web3py.name": { - "message": "Web3.py Extension", + "message": "Web3.pyエクステンション", "description": "Name of the Web3.py Extension SDK" }, "homepage.sdk.section.title": { - "message": "SDK Documentation", + "message": "SDKドキュメント", "description": "Title of the SDK documentation section" }, "homepage.sdk.section.heading": { - "message": "Build freely with tools tailored for your language.", + "message": "あなたの言語に合わせたツールで自由にビルド。", "description": "Main heading of the SDK section" }, "homepage.sdk.section.description": { - "message": "Seamlessly integrate with Kaia Network using our enhanced SDKs for JavaScript, Java, Python and more. Built on trusted foundations like Ethers, Web3.js, Web3j, and Web3.py, our libraries give you the power to submit transactions, read smart contracts, and develop complex applications with extended functionality - all in your preferred programming language.", + "message": "JavaScript、Java、Pythonなどのための強化されたSDKを使用して、Kaia Networkとシームレスに統合できます。Ethers、Web3.js、Web3j、Web3.pyのような信頼できる基盤の上に構築された当社のライブラリは、トランザクションの送信、スマートコントラクトの読み取り、拡張機能を備えた複雑なアプリケーションの開発を可能にします。", "description": "Description of Kaia Network's SDK offerings" }, "homepage.sdk.section.viewMore": { - "message": "View More SDKs", + "message": "SDKをもっと見る", "description": "Link text to view additional SDKs" }, "theme.blog.author.noPosts": { - "message": "This author has not written any posts yet.", + "message": "この著者はまだ記事を書いていない。", "description": "The text for authors with 0 blog post" + }, + "theme.feedback.helpful": { + "message": "このページは役に立ちましたか？", + "description": "The text asking if the page is helpful" } } diff --git a/i18n/ja/docusaurus-plugin-content-blog/options.json b/i18n/ja/docusaurus-plugin-content-blog/options.json index 9239ff706c28..7abfbdd6766c 100644 --- a/i18n/ja/docusaurus-plugin-content-blog/options.json +++ b/i18n/ja/docusaurus-plugin-content-blog/options.json @@ -1,14 +1,14 @@ { "title": { - "message": "Blog", + "message": "ブログ", "description": "The title for the blog used in SEO" }, "description": { - "message": "Blog", + "message": "ブログ", "description": "The description for the blog used in SEO" }, "sidebar.title": { - "message": "Recent posts", + "message": "最近の投稿", "description": "The label for the left sidebar" } } diff --git a/i18n/ja/docusaurus-plugin-content-docs/current.json b/i18n/ja/docusaurus-plugin-content-docs/current.json index 637cbdb3dd34..333b2b95c0a0 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current.json +++ b/i18n/ja/docusaurus-plugin-content-docs/current.json @@ -1,106 +1,106 @@ { "version.label": { - "message": "Current", + "message": "現在", "description": "The label for version current" }, "sidebar.learnSidebar.category.Transactions": { - "message": "Transactions", + "message": "トランザクション", "description": "The label for category Transactions in sidebar learnSidebar" }, "sidebar.learnSidebar.category.Computation": { - "message": "Computation", + "message": "計算", "description": "The label for category Computation in sidebar learnSidebar" }, "sidebar.buildSidebar.category.Get Started": { - "message": "Get Started", + "message": "スタート", "description": "The label for category Get Started in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Account Basics": { - "message": "Account Basics", + "message": "口座の基本", "description": "The label for category Account Basics in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Smart Contracts": { - "message": "Smart Contracts", + "message": "スマートコントラクト", "description": "The label for category Smart Contracts in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Deploy Smart Contracts": { - "message": "Deploy Smart Contracts", + "message": "スマートコントラクトの導入", "description": "The label for category Deploy Smart Contracts in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Sample Contracts": { - "message": "Sample Contracts", + "message": "サンプル契約", "description": "The label for category Sample Contracts in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Tutorials": { - "message": "Tutorials", + "message": "チュートリアル", "description": "The label for category Tutorials in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Tools": { - "message": "Tools", + "message": "ツール", "description": "The label for category Tools in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Wallets": { - "message": "Wallets", + "message": "財布", "description": "The label for category Wallets in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Wallet Libraries": { - "message": "Wallet Libraries", + "message": "財布ライブラリ", "description": "The label for category Wallet Libraries in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Oracles": { - "message": "Oracles", + "message": "神託", "description": "The label for category Oracles in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Indexers": { - "message": "Indexers", + "message": "インデクサ", "description": "The label for category Indexers in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Cross-chain": { - "message": "Cross-chain", + "message": "クロスチェーン", "description": "The label for category Cross-chain in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Block Explorers": { - "message": "Block Explorers", + "message": "ブロック探検隊", "description": "The label for category Block Explorers in sidebar buildSidebar" }, "sidebar.nodeSidebar.category.Endpoint Node": { - "message": "Endpoint Node", + "message": "エンドポイントノード", "description": "The label for category Endpoint Node in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Core Cell": { - "message": "Core Cell", + "message": "コアセル", "description": "The label for category Core Cell in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Install Core Cell": { - "message": "Install Core Cell", + "message": "コアセルの設置", "description": "The label for category Install Core Cell in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Service Chain": { - "message": "Service Chain", + "message": "サービスチェーン", "description": "The label for category Service Chain in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Quick Start": { - "message": "Quick Start", + "message": "クイックスタート", "description": "The label for category Quick Start in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Configure Service Chain": { - "message": "Configure Service Chain", + "message": "サービスチェーンの設定", "description": "The label for category Configure Service Chain in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Node Package Downloads": { - "message": "Node Package Downloads", + "message": "ノードパッケージダウンロード", "description": "The label for category Node Package Downloads in sidebar nodeSidebar" }, "sidebar.refSidebar.category.RPC API Reference": { - "message": "RPC API Reference", + "message": "RPC APIリファレンス", "description": "The label for category RPC API Reference in sidebar refSidebar" }, "sidebar.refSidebar.category.SDKs and Libraries": { - "message": "SDKs and Libraries", + "message": "SDKとライブラリ", "description": "The label for category SDKs and Libraries in sidebar refSidebar" }, "sidebar.refSidebar.category.API References": { - "message": "API References", + "message": "APIリファレンス", "description": "The label for category API References in sidebar refSidebar" }, "sidebar.refSidebar.category.caver.wallet": { @@ -116,15 +116,15 @@ "description": "The label for category caver.rpc in sidebar refSidebar" }, "sidebar.refSidebar.link.API References": { - "message": "API References", + "message": "APIリファレンス", "description": "The label for link API References in sidebar refSidebar, linking to https://javadoc.io/doc/com.klaytn.caver/core/" }, "sidebar.learnSidebar.category.Transaction Fees": { - "message": "Transaction Fees", + "message": "取引手数料", "description": "The label for category Transaction Fees in sidebar learnSidebar" }, "sidebar.buildSidebar.category.Verify Smart Contracts": { - "message": "Verify Smart Contracts", + "message": "スマートコントラクトの検証", "description": "The label for category Verify Smart Contracts in sidebar buildSidebar" }, "sidebar.refSidebar.category.caver.kct": { @@ -132,43 +132,43 @@ "description": "The label for category caver.kct in sidebar refSidebar" }, "sidebar.learnSidebar.category.Data Management": { - "message": "Data Management", + "message": "データ管理", "description": "The label for category Data Management in sidebar learnSidebar" }, "sidebar.learnSidebar.category.Governance": { - "message": "Governance", + "message": "ガバナンス", "description": "The label for category Governance in sidebar learnSidebar" }, "sidebar.learnSidebar.category.Node Quick Reference": { - "message": "Node Quick Reference", + "message": "ノード・クイック・リファレンス", "description": "The label for category Node Quick Reference in sidebar learnSidebar" }, "sidebar.learnSidebar.category.Transition to Kaia": { - "message": "Transition to Kaia", + "message": "カイアへの移行", "description": "The label for category Transition to Kaia in sidebar learnSidebar" }, "sidebar.buildSidebar.category.Kaia Safe": { - "message": "Kaia Safe", + "message": "カイア・セーフ", "description": "The label for category Kaia Safe in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Node Quick Reference": { - "message": "Node Quick Reference", + "message": "ノード・クイック・リファレンス", "description": "The label for category Node Quick Reference in sidebar buildSidebar" }, "sidebar.buildSidebar.category.Transition to Kaia": { - "message": "Transition to Kaia", + "message": "カイアへの移行", "description": "The label for category Transition to Kaia in sidebar buildSidebar" }, "sidebar.buildSidebar.link.KaiaScan": { - "message": "KaiaScan", + "message": "カイアスキャン", "description": "The label for link KaiaScan in sidebar buildSidebar, linking to https://kaiascan.io/" }, "sidebar.nodeSidebar.category.Node Quick Reference": { - "message": "Node Quick Reference", + "message": "ノード・クイック・リファレンス", "description": "The label for category Node Quick Reference in sidebar nodeSidebar" }, "sidebar.nodeSidebar.category.Transition to Kaia": { - "message": "Transition to Kaia", + "message": "カイアへの移行", "description": "The label for category Transition to Kaia in sidebar nodeSidebar" }, "sidebar.refSidebar.category.ethers-ext < v1.0.1": { @@ -176,35 +176,35 @@ "description": "The label for category ethers-ext < v1.0.1 in sidebar refSidebar" }, "sidebar.refSidebar.category.Account Management": { - "message": "Account Management", + "message": "アカウント管理", "description": "The label for category Account Management in sidebar refSidebar" }, "sidebar.refSidebar.category.Account Key": { - "message": "Account Key", + "message": "アカウント・キー", "description": "The label for category Account Key in sidebar refSidebar" }, "sidebar.refSidebar.category.Sign Transaction": { - "message": "Sign Transaction", + "message": "サイン取引", "description": "The label for category Sign Transaction in sidebar refSidebar" }, "sidebar.refSidebar.category.Sign Message": { - "message": "Sign Message", + "message": "サインメッセージ", "description": "The label for category Sign Message in sidebar refSidebar" }, "sidebar.refSidebar.category.keystore": { - "message": "keystore", + "message": "キーストア", "description": "The label for category keystore in sidebar refSidebar" }, "sidebar.refSidebar.category.Basic Transaction": { - "message": "Basic Transaction", + "message": "基本取引", "description": "The label for category Basic Transaction in sidebar refSidebar" }, "sidebar.refSidebar.category.Fee Delegated Transaction": { - "message": "Fee Delegated Transaction", + "message": "手数料 委任取引", "description": "The label for category Fee Delegated Transaction in sidebar refSidebar" }, "sidebar.refSidebar.category.Smart Contract": { - "message": "Smart Contract", + "message": "スマート契約", "description": "The label for category Smart Contract in sidebar refSidebar" }, "sidebar.refSidebar.category.ethers-ext": { @@ -216,7 +216,7 @@ "description": "The label for category v5 in sidebar refSidebar" }, "sidebar.refSidebar.category.Utils": { - "message": "Utils", + "message": "ユーティリティ", "description": "The label for category Utils in sidebar refSidebar" }, "sidebar.refSidebar.category.v6": { @@ -232,7 +232,7 @@ "description": "The label for category web3j-ext in sidebar refSidebar" }, "sidebar.refSidebar.category.Keystore": { - "message": "Keystore", + "message": "キーストア", "description": "The label for category Keystore in sidebar refSidebar" }, "sidebar.refSidebar.category.web3py-ext": { @@ -240,39 +240,39 @@ "description": "The label for category web3py-ext in sidebar refSidebar" }, "sidebar.refSidebar.category.caver-js": { - "message": "caver-js", + "message": "ケイバージェイエス", "description": "The label for category caver-js in sidebar refSidebar" }, "sidebar.refSidebar.category.caver-java": { - "message": "caver-java", + "message": "ケイバー・ジャバ", "description": "The label for category caver-java in sidebar refSidebar" }, "sidebar.refSidebar.category.Node Quick Reference": { - "message": "Node Quick Reference", + "message": "ノード・クイック・リファレンス", "description": "The label for category Node Quick Reference in sidebar refSidebar" }, "sidebar.refSidebar.category.Transition to Kaia": { - "message": "Transition to Kaia", + "message": "カイアへの移行", "description": "The label for category Transition to Kaia in sidebar refSidebar" }, "sidebar.refSidebar.doc.Getting-Started": { - "message": "Getting-Started", + "message": "はじめに", "description": "The label for the doc item Getting-Started in sidebar refSidebar, linking to the doc references/sdk/web3py-ext/getting-started" }, "sidebar.buildSidebar.category.Hardware Wallets": { - "message": "Hardware Wallets", + "message": "ハードウェア財布", "description": "The label for category Hardware Wallets in sidebar buildSidebar" }, "sidebar.miniDappSidebar.category.Build Mini dApps on LINE with Unity": { - "message": "Build Mini dApps on LINE with Unity", + "message": "UnityでLINEのミニdAppを作る", "description": "The label for category Build Mini dApps on LINE with Unity in sidebar miniDappSidebar" }, "sidebar.miniDappSidebar.category.Node Quick Reference": { - "message": "Node Quick Reference", + "message": "ノード・クイック・リファレンス", "description": "The label for category Node Quick Reference in sidebar miniDappSidebar" }, "sidebar.miniDappSidebar.category.Transition to Kaia": { - "message": "Transition to Kaia", + "message": "カイアへの移行", "description": "The label for category Transition to Kaia in sidebar miniDappSidebar" } } diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/build.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/build.md index 9180c67afb84..91d35f30d9f6 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/build.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/build.md @@ -1,3 +1,3 @@ -# Welcome +# ようこそ -Welcome to the "Build" section of Klaytn. This section is for developers interested in using the Klaytn system for decentralized applications. Here, you can find several tutorials for deploying different types of smart contracts, links for all the available tools and resources. +カイアの「ビルド」セクションへようこそ。 このセクションは、分散型アプリケーションにKaiaシステムを使用することに関心のある開発者向けです。 ここでは、さまざまな種類のスマート・コントラクトをデプロイするためのチュートリアルや、利用可能なすべてのツールやリソースへのリンクを見つけることができます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/account.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/account.md index e4e79f5109d7..e8b7ba13f797 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/account.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/account.md @@ -1,20 +1,20 @@ -# Account Basics +# 口座の基本 -**`WARNING`**: Remember your password. If you lose the password of your account, you will not be able to access that account. **There is no** _**forgot my password**_ **option here. Never forget it.** +\*\*警告パスワードを忘れないでください。 アカウントのパスワードを紛失すると、そのアカウントにアクセスできなくなります。 \*\*パスワードを忘れました。 決して忘れてはならない。 -Klaytn provides two handy command-line tools, `ken` and `JavaScript console`, for developers to manage accounts. Note that exporting your private key in an unencrypted format is NOT supported. +Kaiaは開発者がアカウントを管理するために、`ken`と`JavaScript console`という2つの便利なコマンドラインツールを提供している。 暗号化されていない形式で秘密鍵をエクスポートすることはサポートされていません。 ## ken -The Klaytn Endpoint Node binary `ken` provides account management via the `account` command. The command `account` lets you create new accounts, lists all existing accounts, imports a private key into a new account, migrates to the newest key format, and changes your password. +Kaia エンドポイントノードのバイナリ `ken` は `account` コマンドでアカウント管理を行う。 `account`コマンドを使うと、新しいアカウントの作成、既存のアカウントの一覧表示、秘密鍵の新しいアカウントへのインポート、最新の鍵フォーマットへの移行、パスワードの変更ができます。 -### Usage +### 使用方法 ```bash $ ken account [options...] [arguments...] ``` -**Commands** +\*\*コマンド ```bash $ ken account -help @@ -27,7 +27,7 @@ COMMANDS: ... ``` -You can get info about subcommands by `ken account --help`. +`ken account --help`でサブコマンドの情報を得ることができる。 ```text $ ken account list --help @@ -35,7 +35,7 @@ list [command options] [arguments...] Print a short summary of all accounts -KLAY OPTIONS: +KAIA OPTIONS: --dbtype value Blockchain storage database type ("leveldb", "badger") (default: "leveldb") --datadir "/Users/ethan/Library/KEN" Data directory for the databases and keystore --keystore Directory for the keystore (default = inside the datadir) @@ -44,25 +44,25 @@ DATABASE OPTIONS: --db.no-partitioning Disable partitioned databases for persistent storage ``` -### Data Directory +### データディレクトリ -Keystore files are stored under `/keystore`. You can specify the data directory as below. It is highly recommended to execute `ken account` command with `--datadir` option. Make the data directory point to the `DATA_DIR` set in the `kend.conf` to seamlessly share the accounts with your Endpoint Node. +キーストア・ファイルは、`/keystore`に保存される。 データ・ディレクトリは以下のように指定できます。 `ken account`コマンドに--datadir`オプションを付けることを強く推奨する。 Endpoint Node とシームレスにアカウントを共有するために、`kend.conf`で設定した`DATA_DIR\` をデータディレクトリの指すようにします。 ```bash $ ken account new --datadir $ ken account new --datadir "~/kend_home" ``` -If you do not specify the data directory, the default location is as follows. +データ・ディレクトリを指定しない場合、デフォルトの場所は以下のようになる。 - Mac: `~/Library/KEN` - Linux: `~/.ken` -## JavaScript Console +## JavaScriptコンソール -To connect to the JavaScript console, an EN must be in running status. For more information, see [Launching an EN](../../smart-contracts/deploy/ken.md). Start an EN and attach to the console as follows. +JavaScriptコンソールに接続するには、ENが実行中でなければなりません。 詳しくは、[ENを起動する](../../smart-contracts/deploy/ken.md)を参照してください。 ENを起動し、以下のようにコンソールに接続する。 -### Usage +### 使用方法 ```bash $ kend start @@ -78,18 +78,18 @@ instance: Kaia/vX.X.X/XXXX-XXXX/goX.X.X > ``` -**Commands** +\*\*コマンド -Type `personal` or `klay` to get the list of available functions. In this tutorial, we are going to visit the following functions. +`personal`または`kaia`と入力すると、利用可能な機能のリストが表示される。 このチュートリアルでは、以下の関数を訪ねます。 ```bash > personal.newAccount() > personal.importRawKey() > personal.unlockAccount() -> klay.accounts -> klay.getBalance() +> kaia.accounts +> kaia.getBalance() ``` -### Data Directory +### データディレクトリ -When you create an account, the keystore file is stored under `/keystore`. The `` is the `DATA_DIR` set in the `kend.conf`. If you follow the quick start guide with the given example, it must be `~/kend_home`. +アカウントを作成すると、キーストア・ファイルは`/keystore`に保存される。 `` は `kend.conf` で設定した `DATA_DIR` である。 クイックスタートガイドの例に従えば、`~/kend_home`でなければならない。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/creating-accounts.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/creating-accounts.md index 8f3153ebb379..5b284d268536 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/creating-accounts.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/creating-accounts.md @@ -1,16 +1,16 @@ -# Create Accounts +# アカウント作成 -## Creating a New Account +## 新規アカウントの作成 -This will create a new account and print the address on the screen. A keystore file is created under the data directory. +これで新しいアカウントが作成され、住所が画面に印刷される。 データ・ディレクトリの下にキーストア・ファイルが作成される。 -**Klaytn Keystore File** +**Kaia Keystore File** -When you create an account, a keystore file is created. The keystore file is an encrypted version of your unique Klaytn private key that you will use to sign your transactions. The keystore file name has the following format: +アカウントを作成すると、キーストア・ファイルが作成される。 キーストアファイルは、トランザクションに署名するために使用する、あなた独自のKaia秘密鍵の暗号化バージョンです。 キーストア・ファイル名は以下のフォーマットである： - `UTC---
` -It is safe to transfer the entire directory or the individual keystore file therein between Klaytn nodes. Note that in case you are adding keys to your node from a different node, the order of accounts may change. So make sure you do not rely on the index in your scripts or code snippets. +Kaiaノード間で、ディレクトリ全体または個々のキーストア・ファイルを転送することは安全です。 別のノードから自分のノードにキーを追加する場合、アカウントの順序が変わる可能性があることに注意してください。 そのため、スクリプトやコード・スニペットでインデックスに依存しないように注意してください。 ### ken @@ -20,7 +20,7 @@ $ ken account new --password --datadir $ ken account new --password <(echo $mypassword) --datadir ``` -**`WARNING`**: Note that using a password file is meant for testing only; it is a bad idea to save your password in a file or expose it in any other way. If you use the password flag with a password file, best to make sure the file is not readable or even listable for anyone but you. You achieve this with: +\*\*警告パスワードをファイルに保存したり、その他の方法で公開したりするのは良くない考えです。 パスワードファイルでパスワードフラグを使う場合は、そのファイルが自分以外には読めないように、あるいはリストアップできないようにするのが一番だ。 これを達成するには ```bash $ touch /path/to/password @@ -30,23 +30,23 @@ I type my pass here ^D ``` -### JavaScript Console +### JavaScriptコンソール -On the console, you can call the following function to create an account: +コンソールでは、以下の関数を呼び出してアカウントを作成することができる： ```javascript > personal.newAccount("passphrase") ``` -The account is saved in an encrypted format. You **must** remember this passphrase to unlock your account in the future. +アカウントは暗号化された形式で保存されます。 今後アカウントのロックを解除するには、このパスフレーズを覚えておく必要があります。 -## Importing an Account +## アカウントのインポート -You can import an account using a keyfile. The keyfile is assumed to contain an unencrypted private key as canonical EC raw bytes encoded into hex. In simpler terms, it is a private key in plain text without the leading `0x`. +キーファイルを使用してアカウントをインポートできます。 keyfileには、暗号化されていない秘密鍵が、16進数にエンコードされた正規のEC rawバイトとして格納されているものとする。 簡単に言えば、先頭の `0x` を除いたプレーンテキストの秘密鍵である。 -This imports an unencrypted private key from the given keyfile, creates a new account, generates a keystore file under the data directory, and prints the address in the console. You must remember the passphrase to unlock your account in the future. +これは、与えられたキーファイルから暗号化されていない秘密鍵をインポートし、新しいアカウントを作成し、データ・ディレクトリの下にキーストア・ファイルを生成し、コンソールにアドレスを表示する。 今後アカウントのロックを解除するには、パスフレーズを覚えておく必要があります。 -**NOTE**: If you can directly copy your keystore files to another Klaytn instance, this import/export mechanism is not needed. +**注**：キーストアファイルを別のKaiaインスタンスに直接コピーできる場合、このインポート/エクスポート機構は必要ありません。 ### ken @@ -55,13 +55,13 @@ $ ken account import --datadir $ ken account import --password --datadir ``` -### JavaScript Console +### JavaScriptコンソール ```bash > personal.importRawKey('{private key}', 'mypassword') "0xfa415bb3e6231f488ff39eb2897db0ef3636dd32"​ -// Using a Klaytn wallet key +// Using a Kaia wallet key > personal.importRawKey('{private key}0x000x{address}', 'mypassword') "0xfa415bb3e6231f488ff39eb2897db0ef3636dd32" ``` diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/managing-accounts.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/managing-accounts.md index 87f4959a10c7..dd91fb3ba279 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/managing-accounts.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/account/managing-accounts.md @@ -1,12 +1,12 @@ -# Manage Accounts +# アカウント管理 -## List Your Accounts +## 口座リスト -This will return the list of all accounts created under the data directory. +これは、データ・ディレクトリの下に作成されたすべてのアカウントのリストを返す。 ### ken -From the command line, call the CLI with: +コマンドラインから、次のようにCLIを呼び出す： ```bash $ ken account list --datadir @@ -15,26 +15,26 @@ Account #0: {bfc22a57999459b0c2ce6337deb9287e7a970e02} keystore:///Users/usernam Account #1: {47bd2e9565cbe1789454718d6cf1778d7ea557aa} keystore:///Users/username/kend_home/keystore/UTC--2019-03-26T07-04-44.840061000Z--47bd2e9565cbe1789454718d6cf1778d7ea557aa ``` -**NOTE**: This order of returned account list can change if you copy keystore files from other nodes or remove the files. Therefore, make sure you either do not rely on the index or make sure if you copy or remove keystore files you check and update your account indexes in your scripts. +**注**：他のノードからキーストア・ファイルをコピーしたり、ファイルを削除したりすると、返されるアカウント・リストの順序が変わることがあります。 したがって、インデックスに依存しないようにするか、キーストア・ファイルをコピーまたは削除した場合は、スクリプトでアカウント・インデックスをチェックして更新するようにしてください。 -### JavaScript Console +### JavaScriptコンソール -When using the console: +コンソールを使用する場合 ```javascript -> klay.accounts +> kaia.accounts ["bfc22a57999459b0c2ce6337deb9287e7a970e02", "47bd2e9565cbe1789454718d6cf1778d7ea557aa"] ``` -## Unlock Accounts +## アカウントのロック解除 -If you want to use an account non-interactively, you need to unlock it. +アカウントをインタラクティブに使用しない場合は、ロックを解除する必要があります。 ### ken -You can unlock accounts and start the EN on the command line with the `--unlock "{address},{address}"` option which takes a comma-separated list of accounts (in hex or index) as an argument so you can unlock the accounts programmatically for one session. This is useful if you want to use your account from dApps via RPC. `--unlock` will unlock the first account in the list. This is useful when you created your account programmatically, you do not need to know the actual account to unlock it. +You can unlock accounts and start the EN on the command line with the `--unlock "{address},{address}"` option which takes a comma-separated list of accounts (in hex or index) as an argument so you can unlock the accounts programmatically for one session. これは、RPC経由でdAppsからアカウントを使用したい場合に便利です。 `unlock`はリストの最初のアカウントのロックを解除する。 これは、プログラムでアカウントを作成した場合に便利で、実際のアカウントを知らなくてもロックを解除できる。 -Create an account and start a node with the account unlocked: +アカウントを作成し、ロックを解除した状態でノードを開始する： ```bash $ ken account new --password <(echo this is not secret) --datadir @@ -49,15 +49,15 @@ $ ken --unlock "2" --datadir $ ken --unlock "bfc22a57999459b0c2ce6337deb9287e7a970e02" --datadir ``` -The command line allows you to unlock multiple accounts. In this case, the argument to unlock is a comma-separated list of account addresses or indexes. +コマンドラインを使えば、複数のアカウントのロックを解除できる。 この場合、unlockの引数は、アカウント・アドレスまたはインデックスをカンマで区切ったリストである。 ```bash $ ken --unlock "0x407d73d8a49eeb85d32cf465507dd71d507100c1,0,5,e470b1a7d2c9c5c6f03bbaa8fa20db6d404a0c32" --datadir ``` -If this construction is used non-interactively, your password file will need to contain the respective passwords for the accounts in question, one per line. +この構文を非対話的に使用する場合、パスワードファイルには、該当するアカウントのパスワードを1行に1つずつ記述する必要がある。 -### JavaScript Console +### JavaScriptコンソール On the console you can also unlock accounts (one at a time) for a duration (in seconds). @@ -65,59 +65,59 @@ On the console you can also unlock accounts (one at a time) for a duration (in s > personal.unlockAccount(address, "password", 300) ``` -Note that we do NOT recommend using the password argument here, since the console history is logged, so you may compromise your account. You have been warned. +コンソールの履歴が記録されるため、アカウントが危険にさらされる可能性があります。 あなたは警告されている。 -## Check Account Balance +## 口座残高の確認 ### ken -n/a +該当なし -### JavaScript Console +### JavaScriptコンソール -To check your account balance: +口座残高の確認 ```javascript -> klay.fromPeb(klay.getBalance("{account}"), "KLAY") +> kaia.fromPeb(kaia.getBalance("{account}"), "KAIA") 6.5 ``` -Print all balances with a JavaScript function: +JavaScript関数ですべての残高を表示する： ```javascript function checkAllBalances() { var totalBal = 0; - for (var acctNum in klay.accounts) { - var acct = klay.accounts[acctNum]; + for (var acctNum in kaia.accounts) { + var acct = kaia.accounts[acctNum]; - var acctBal = klay.fromPeb(klay.getBalance(acct), "KLAY"); + var acctBal = kaia.fromPeb(kaia.getBalance(acct), "KAIA"); totalBal += parseFloat(acctBal); - console.log("klay.accounts[" + acctNum + "]: \t" + acct + " \tbalance: " + acctBal + "KLAY"); + console.log("kaia.accounts[" + acctNum + "]: \t" + acct + " \tbalance: " + acctBal + "KAIA"); } - console.log("Total balance: " + totalBal + " KLAY"); + console.log("Total balance: " + totalBal + " KAIA"); }; ``` -That can then be executed with: +と実行することができる： ```javascript > checkAllBalances(); -klay.accounts[0]: 0xd1ade25ccd3d550a7eb532ac759cac7be09c2719 balance: 63.11848 KLAY -klay.accounts[1]: 0xda65665fc30803cb1fb7e6d86691e20b1826dee0 balance: 0 KLAY -klay.accounts[2]: 0xe470b1a7d2c9c5c6f03bbaa8fa20db6d404a0c32 balance: 1 KLAY -klay.accounts[3]: 0xf4dd5c3794f1fd0cdc0327a83aa472609c806e99 balance: 6 KLAY +kaia.accounts[0]: 0xd1ade25ccd3d550a7eb532ac759cac7be09c2719 balance: 63.11848 KAIA +kaia.accounts[1]: 0xda65665fc30803cb1fb7e6d86691e20b1826dee0 balance: 0 KAIA +kaia.accounts[2]: 0xe470b1a7d2c9c5c6f03bbaa8fa20db6d404a0c32 balance: 1 KAIA +kaia.accounts[3]: 0xf4dd5c3794f1fd0cdc0327a83aa472609c806e99 balance: 6 KAIA ``` -Since this function will disappear after restarting `ken`, it can be helpful to store commonly used functions to be called later. +この関数は `ken` を再起動すると消えてしまうので、よく使う関数を保存しておくと後で呼び出すときに便利である。 -First, save the `checkAllBalances()` function definition to a file on your computer. For example, `/Users/username/klayload.js`. Then load the file from the interactive console: +まず、`checkAllBalances()`関数の定義をコンピューター上のファイルに保存する。 例えば、`/Users/username/klayload.js`である。 その後、対話型コンソールからファイルをロードする： ```javascript > loadScript("/Users/username/klayload.js") true ``` -The file will modify your JavaScript environment as if you have typed the commands manually. Feel free to experiment! +このファイルは、あたかも手動でコマンドを入力したかのように、あなたのJavaScript環境を変更する。 自由に実験してほしい！ diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/before-you-start.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/before-you-start.md index 5743ced26393..5a825cdc0380 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/before-you-start.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/before-you-start.md @@ -1,31 +1,31 @@ -# Before You Start +# 始める前に -**Klaytn Networks** +**カイア・ネットワークス** - Baobab testnet - Cypress mainnet -**Endpoint Node** +\*\*エンドポイントノード -- Your [Endpoint Node](../../nodes/endpoint-node/endpoint-node.md) is needed to connect to the Klaytn network and to issue an API call or send a transaction. -- `ken` is a Klaytn Endpoint Node binary. `ken` exposes two interfaces, a [command-line interface](../../nodes/endpoint-node/ken-cli-commands.md) and the [JSON-RPC APIs](../../../references/json-rpc/klay/account-created). `ken` runs on Linux and MacOS. -- `ken` CLI comes with several utility and node management functions. +- エンドポイントノード](../../nodes/endpoint-node/endpoint-node.md)は、Kaiaネットワークに接続し、APIコールを発行したりトランザクションを送信したりするために必要です。 +- `ken`はKaia Endpoint Nodeのバイナリである。 `ken` は2つのインターフェイス、[コマンドラインインターフェイス](../../nodes/endpoint-node/ken-cli-commands.md)と[JSON-RPC API](../../../references/json-rpc/klay/account-created)を公開している。 `ken`はLinuxとMacOSで動作する。 +- `ken` CLI はいくつかのユーティリティとノード管理機能を備えている。 -**Smart Contract Development** +**スマートな契約開発** -- [Kaia Plugin for Remix](https://ide.kaia.io) - Kaia Plugin for Remix, a browser-based compiler and IDE. -- [Truffle](https://github.com/trufflesuite/truffle) - An open-source tool for developing smart contracts in Solidity. -- [Hardhat](https://hardhat.org/hardhat-runner/docs/getting-started) - A development environment for smart contracts and dApps. -- [Foundry](https://book.getfoundry.sh/) - Foundry is a smart contract development toolchain. -- [Thirdweb](https://portal.thirdweb.com/) - Thirdweb is a complete web3 development framework that provides services to build, manage, and analyze web3 applications. +- [Kaia Plugin for Remix](https://ide.kaia.io) - ブラウザベースのコンパイラとIDEであるRemix用のKaiaプラグイン。 +- [Truffle](https://github.com/trufflesuite/truffle) - Solidityでスマートコントラクトを開発するためのオープンソースツール。 +- [Hardhat](https://hardhat.org/hardhat-runner/docs/getting-started) - スマートコントラクトとdAppsの開発環境。 +- [Foundry](https://book.getfoundry.sh/) - Foundryはスマートコントラクト開発ツールチェーンである。 +- [Thirdweb](https://portal.thirdweb.com/) - Thirdwebは、Web3アプリケーションを構築、管理、分析するサービスを提供する完全なWeb3開発フレームワークです。 -**Klaytn SDKs** +**カイアSDK** -- [caver-js](../../references/sdk/caver-js/caver-js.md) : A JavaScript library that implements the Klaytn JSON-RPC APIs. -- [caver-java](../../references/sdk/caver-java/caver-java.md) : A Java library that implements the Klaytn JSON-RPC APIs. +- [caver-js](../../references/sdk/caver-js/caver-js.md) ：Kaia JSON-RPC APIを実装するJavaScriptライブラリ。 +- [caver-java](../../references/sdk/caver-java/caver-java.md) ：Kaia JSON-RPC APIを実装したJavaライブラリ。 -**Klaytn Toolkits** +**カイア・ツールキット** -- [Kaiascope](https://kaiascope.com/) - A block and transaction explorer. -- [Kaia Wallet](https://www.kaiawallet.io/) - A browser extension wallet for the Kaia Network. -- [Klaytn Contracts Wizard](https://wizard.klaytn.foundation/) - An interactive generator to bootstrap your smart contract and learn about Klaytn Contracts. +- [Kaiascope](https://kaiascope.com/) - ブロックとトランザクションのエクスプローラ。 +- [Kaia Wallet](https://www.kaiawallet.io/) - カイアネットワークのブラウザ拡張ウォレット。 +- [Kaia Contracts Wizard](https://wizard.klaytn.foundation/) - スマートコントラクトをブートストラップし、Kaiaコントラクトについて学ぶためのインタラクティブなジェネレーターです。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/get-started.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/get-started.md index 080f1c1ee2ff..ad66030d8ad5 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/get-started.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/get-started.md @@ -1,6 +1,6 @@ -# Get Started +# スタート -Try and get familiar with Klaytn. This chapter is the starting point of your journey to Klaytn dApps. +カイアのことをよく知ろうとする。 この章は、カイアdAppsへの旅の出発点です。 ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/getting-kaia.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/getting-kaia.md index 1fcef2b065d8..0061c3980a43 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/getting-kaia.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/getting-kaia.md @@ -1,15 +1,15 @@ -# Get KAIA +# KAIAを入手 -## Kairos Testnet and Faucet +## カイロス・テストネットと蛇口 -The **testnet KAIA** faucet runs on the Kairos network. The faucet can be accessed from the [Kairos Kaia Faucet](https://faucet.kaia.io). To receive testnet KAIA, you should have a valid Kaia account. +水栓はKairosネットワーク上で動作します。 この蛇口は[Kairos Kaia Faucet](https://faucet.kaia.io)からアクセスできる。 テストネットKAIAを受信するには、有効なKaiaアカウントが必要です。 -- Load your account into the wallet using your private key or keystore file. Testnet KAIA will be sent to the loaded account. -- Clicking `Run Faucet` button will send you 50 testnet KAIA and update your balance. Note that you can run the faucet for each account once every 24 hours. +- 秘密鍵またはキーストアファイルを使用して、アカウントをウォレットにロードします。 Testnet KAIAはロードされたアカウントに送信されます。 +- `Run Faucet`ボタンをクリックすると、50テストネットKAIAが送信され、残高が更新されます。 なお、各アカウントの蛇口は24時間に1回だけ動かすことができる。 -## KAIA Exchange List +## KAIA交換リスト -KAIA is listed on various exchanges. Please find the list of KAIA exchanges through the following links. +KAIAは様々な取引所に上場している。 KAIAの交換リストは以下のリンクからご覧ください。 -- [KAIA exchanges listed at CoinGecko](https://www.coingecko.com/en/coins/klay#markets) -- [KAIA exchanges listed at CoinMarketCap](https://coinmarketcap.com/currencies/klaytn/markets/) +- [CoinGeckoにリストされているKAIA取引所](https://www.coingecko.com/en/coins/klay#markets) +- [CoinMarketCapに掲載されているKAIA取引所](https://coinmarketcap.com/currencies/klaytn/markets/) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/hardhat.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/hardhat.md index 5435d92bcb6a..9f2d8223f8fb 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/hardhat.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/get-started/hardhat.md @@ -1,119 +1,119 @@ -# Deploy your first smart contract using Hardhat +# Hardhatを使って最初のスマート・コントラクトをデプロイする ![](/img/banners/kaia-hardhat.png) -## Introduction +## はじめに -This section will guide you through deploying a Soulbound Token to the Klaytn Baobab Network using [Hardhat](https://hardhat.org/). +このセクションでは、[Hardhat](https://hardhat.org/)を使用してKaia KairosネットワークにSoulbound Tokenを配備する方法を説明します。 -Hardhat is a smart-contract development environment that will help you: +Hardhatは、スマート・コントラクト開発環境です： -- Develop and compile smart contracts. -- Debug, test, and deploy smart contracts and dApps. +- スマートコントラクトの開発とコンパイル +- スマートコントラクトとdAppsのデバッグ、テスト、デプロイ。 -Soul-bound tokens(SBTs) are non-transferable NFTs. Meaning once acquired, they cannot be sold or transferred to another user. To learn more about SBTs, how it works and their use case, you can check out this [reference article](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) published by Vitalik Buterin. +ソウル・バウンド・トークン（SBT）は譲渡不可能なNFTである。 つまり、一度取得した情報を他のユーザーに販売したり譲渡したりすることはできません。 SBTの詳細、仕組み、使用例については、Vitalik Buterinが発表したこちらの[参考記事](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)をご覧いただきたい。 -By the end of this guide you will be able to: +このガイドの終わりには、あなたは次のことができるようになる： -- Set up a Hardhat project on Klaytn. -- Create a simple soul-bound token. -- Compile your smart contract using Hardhat. -- Test, deploy, and interact with your smart contract using Hardhat. -- Explore Hardhat forking feature. +- KaiaでHardhatプロジェクトを立ち上げる。 +- シンプルなソウル・バウンド・トークンを作る。 +- Hardhatを使ってスマート・コントラクトをコンパイルする。 +- Hardhatを使用して、スマート・コントラクトをテスト、デプロイ、対話します。 +- ハードハットのフォーク機能を探る -## Pre-requisites +## 前提条件 -To follow this tutorial, the following are the prerequisites: +このチュートリアルに従うには、次のことが前提条件となる： - Code editor: a source-code editor such [VS-Code](https://code.visualstudio.com/download). -- [Metamask](../tutorials/connecting-metamask.mdx#install-metamask): used to deploy the contracts, sign transactions and interact with the contracts. -- RPC Endpoint: you can get this from one of the supported [Endpoint Providers](../../references/public-en.md). -- Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. -- [NodeJS and NPM](https://nodejs.org/en/) +- [メタマスク](../tutorials/connecting-metamask.mdx#install-metamask)：コントラクトのデプロイ、トランザクションへの署名、コントラクトとの対話に使用される。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダ](../../references/public-en.md)の1つから取得できます。 +- [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 +- [NodeJSとNPM](https://nodejs.org/en/) -## Setting Up Your Development Environment +## 開発環境のセットアップ -To make use of hardhat, we need to set up our development environment and get hardhat installed. Let's do this in the following steps: +ハードハットを利用するには、開発環境を整え、ハードハットをインストールする必要がある。 次のステップでやってみよう： -**Step 1**: Create a project directory +\*\*ステップ1プロジェクトディレクトリの作成 ```bash mkdir soulbound-tokens cd soulbound-tokens ``` -**Step 2**: Initialize an npm project +**ステップ 2**：npmプロジェクトを初期化する -Paste this command in your terminal to create a package.json file +以下のコマンドをターミナルに貼り付け、package.jsonファイルを作成する。 ```bash npm init -y ``` -**Step 3**: Install hardhat and other dependencies: +**ステップ 3**：ハードハットとその他の依存関係をインストールします： -- Paste the code below in your terminal to install hardhat +- 以下のコードをターミナルに貼り付け、hardhatをインストールする。 ```bash npm install --save-dev hardhat ``` -- Paste the code below to install other dependencies +- 以下のコードを貼り付けて、他の依存関係をインストールする。 ```bash npm install dotenv @kaiachain/contracts ``` -> Note: This installs other dependencies needed for this project ranging from `hardhat`, `klaytn/contract`, `dotenv` et al. +> 注: `hardhat`、`klaytn/contract`、`dotenv` など、このプロジェクトに必要な他の依存関係をインストールする。 -**Step 4**: Initialise a hardhat project: +**ステップ 4**：ハードハットプロジェクトを初期化する： -Run the command below to initiate an hardhat project +ハードハット・プロジェクトを開始するには、以下のコマンドを実行する。 ```bash npx hardhat ``` -For this guide, you'll be selecting a typescript project as seen below: +このガイドでは、以下のようにタイプスクリプト・プロジェクトを選択する： ![](/img/build/get-started/hardhat-init.png) ![](/img/build/get-started/hardhat-init-ii.png) -> Note: While initializing the project, you will get a prompt to install `hardhat-toolbox` plugin. The plugin bundles all the commonly used packages and Hardhat plugins recommended to start developing with Hardhat. +> 注意: プロジェクトを初期化する際に、`hardhat-toolbox`プラグインをインストールするようプロンプトが表示される。 このプラグインは、Hardhatでの開発を開始するために推奨される、一般的に使用されるパッケージとHardhatプラグインをすべてバンドルしています。 -After initializing a hardhat project, your current directory should include: +ハードハット・プロジェクトを初期化した後、カレント・ディレクトリーには以下のものが含まれているはずだ： -**contracts/** – this folder contains smart contract code. +**contracts/**-このフォルダにはスマート・コントラクトのコードが含まれている。 **scripts/** – this folder contains code that deploys your contracts on the blockchain network. -**test/** – this folder contains all unit tests that test your smart contract. +**test/** - このフォルダには、スマート・コントラクトをテストするすべてのユニットテストが含まれています。 -**hardhat.config.js** – this file contains configurations important for the work of Hardhat and the deployment of the soul-bound token. +**hardhat.config.js** - このファイルには、Hardhatの動作とソウル・バウンド・トークンの配備に重要な設定が含まれています。 -**Step 5**: Create a .env file +**ステップ5**：.envファイルを作成する -Now create your .env file in the project folder. This file helps us load environment variables from an .env file into process.env. +プロジェクト・フォルダーに.envファイルを作成する。 このファイルは、.envファイルからprocess.envに環境変数をロードするのに役立つ。 -- Paste this command in your terminal to create a .env file +- 以下のコマンドをターミナルに貼り付け、.envファイルを作成する。 ```bash touch .env ``` -- After creating our file, let's configure our .env file to look like this: +- ファイルを作成したら、.envファイルを次のように設定しよう： ```js - KAIROS_TESTNET_URL= "Your Kairos RPC link" - PRIVATE_KEY= "your private key copied from MetaMask wallet" + KAIROS_TESTNET_URL= "あなたのカイロスRPCリンク" + PRIVATE_KEY= "MetaMaskウォレットからコピーしたあなたの秘密鍵" ``` -> Note: You can also choose to use the [configuration variable](https://hardhat.org/hardhat-runner/docs/guides/configuration-variables) functionality provided by hardhat to configure variables that shouldn't be included in the code repository. +> 注：コードリポジトリに含めるべきでない変数を設定するために、hardhatが提供する[設定変数](https://hardhat.org/hardhat-runner/docs/guides/configuration-variables)機能を使うこともできます。 -**Step 6**: Setup Hardhat Configs +**ステップ 6**：ハードハット設定のセットアップ -Modify your `hardhat.config.js` with the following configurations: +以下の設定で `hardhat.config.js` を修正する： ```js require("@nomicfoundation/hardhat-toolbox"); @@ -134,17 +134,17 @@ module.exports = { ``` -Now that we have our development environment all set, let's get into writing our soul-bound token smart contract. +さて、開発環境はすべて整ったので、ソウル・バウンド・トークン・スマート・コントラクトの作成に取りかかろう。 -## Creating SBT Smart Contract +## SBTスマートコントラクトの作成 -In this section, you will use the [Kaia Contracts](https://github.com/kaiachain/kaia-contracts): a library for secure smart contract development built on a solid foundation of community-vetted code. It is a fork of open zeppelin contracts. +このセクションでは、[Kaia Contracts](https://github.com/kaiachain/kaia-contracts)を使用します。これは、コミュニティによって検証されたコードの強固な基盤の上に構築された、安全なスマート・コントラクト開発のためのライブラリです。 これはオープン・ツェッペリン契約のフォークである。 -> Note: You already installed this library in **step 3** of the `Setting Development Environment` section. +> 注：このライブラリは`開発環境の設定`セクションの**ステップ3**でインストール済みです。 -**Step 1**: Select the contracts folder in the Explorer pane, click the New File button and create a new file named `SBT.sol` +**ステップ 1**: エクスプローラーペインで契約フォルダを選択し、「新規作成」ボタンをクリックして、`SBT.sol`という名前の新しいファイルを作成します。 -**Step 2**: Open the file and paste the following code: +\*\*ステップ2ファイルを開き、以下のコードを貼り付けます： ```js // SPDX-License-Identifier: MIT @@ -178,21 +178,21 @@ contract SoulBoundToken is KIP17, Ownable { } ``` -**Code Walkthrough** +\*\*コード・チュートリアル -This is your smart contract. **line 1** shows that Hardhat uses the Solidity version 0.8.7 or greater. Other than that, it imports KIP17.sol and other supporting contracts. From **lines 6-12**, a smart contract that inherits KIP17 is been created. Also, the token name and symbol was passed in the constructor. +これがスマート・コントラクトだ。 **行目**は、HardhatがSolidityバージョン0.8.7以上を使用していることを示しています。 その他、KIP17.solやその他のサポート契約をインポートする。 6行目から12行目まで\*\*、KIP17を継承したスマートコントラクトが作成されている。 また、コンストラクタにはトークン名とシンボルが渡される。 -As you can see in the code above, the token name and symbol have been set to **SoulBoundToken** and **SBT** respectively. You can change the token name and symbol to anything you desire. +上のコードでわかるように、トークン名とシンボルはそれぞれ**SoulBoundToken**と**SBT**に設定されている。 トークン名とシンボルは好きなものに変更できる。 -One major thing in this contract is that it prohibits token transfer, which makes the issued tokens soulbond. +この契約では、トークンの譲渡が禁止されており、発行されたトークンはソウルボンドとなる。 -## Testing SBT Smart Contract +## SBTスマートコントラクトのテスト -In this section, we would be testing some of our contract functionalities. +このセクションでは、契約機能の一部をテストする。 -**Step 1**: In the Explorer pane, select the test folder and click the New File button to create a new file named `sbtTest.js` +**ステップ 1**：エクスプローラーペインでtestフォルダを選択し、New Fileボタンをクリックして`sbtTest.js`という名前の新規ファイルを作成します。 -**Step 2**: Copy the code below in the `sbtTest.js` file. +**ステップ 2**：以下のコードを `sbtTest.js` ファイルにコピーする。 ```js // This is an example test file. Hardhat will run every *.js file in `test/`, @@ -280,32 +280,32 @@ describe("Token contract", function () { }) ``` -In the code you just copied, line 7 & 12 shows you imported expect from [Chai](https://www.chaijs.com/api/bdd/) and [loadFixture](https://hardhat.org/tutorial/testing-contracts#reusing-common-test-setups-with-fixtures) from hardhat-network-helpers. +あなたがコピーしたコードの7行目と12行目には、hardhat-network-helpersの[Chai](https://www.chaijs.com/api/bdd/)と[loadFixture](https://hardhat.org/tutorial/testing-contracts#reusing-common-test-setups-with-fixtures)からexpectをインポートしたことが示されています。 -The tests above check the following: +上記のテストは以下のことをチェックする： -- Is the owner of a particular token id the same as who it was minted to? -- Did it prohibit transfer of tokens between accounts? +- 特定のトークンのIDの所有者は、それが鋳造された人と同じですか？ +- アカウント間でのトークンの移動は禁止されたのか？ -**Step 3**: To run your test, run the command below: +**ステップ 3**：テストを実行するには、以下のコマンドを実行してください： ```bash -npx hardhat test test/sbtTest.js +npxハードハットテスト test/sbtTest.js ``` ![](/img/build/get-started/sbtTest.png) -For more in-depth guide on testing, please check [Hardhat testing](https://hardhat.org/hardhat-runner/docs/guides/test-contracts). +テストに関するより詳細なガイドについては、[ハードハットテスト](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)をご覧ください。 -## Deploying the smart contract +## スマートコントラクトの導入 -Scripts are JavaScript/Typescript files that help you deploy contracts to the blockchain network. In this section, you will create a script for the smart contract. +スクリプトはJavaScript/Typescriptファイルで、コントラクトをブロックチェーン・ネットワークにデプロイするのに役立ちます。 このセクションでは、スマート・コントラクト用のスクリプトを作成する。 -**Step 1**: In the Explorer pane, select the "scripts" folder and click the New File button to create a new file named `sbtDeploy.js`. +**ステップ 1**：エクスプローラーペインで "scripts "フォルダを選択し、"New File "ボタンをクリックして`sbtDeploy.js`という名前の新規ファイルを作成する。 -**Step 2**: Copy and paste the following code inside the file. +\*\*ステップ2以下のコードをコピーし、ファイル内に貼り付けます。 -> Note: input your MetaMask wallet address in the `deployerAddr` variable. +> 注意: 変数 `deployerAddr` には MetaMask ウォレットのアドレスを入力してください。 ```js const { ethers } = require("hardhat"); @@ -334,7 +334,7 @@ main().catch((error) => { }); ``` -**Step 3**: In the terminal, run the following command which tells Hardhat to deploy your SBT token on the Klaytn Test Network (Baobab) +**ステップ3**：ターミナルで、HardhatにSBTトークンをKaia Test Network (Kairos)にデプロイするように指示する以下のコマンドを実行します。 ```bash npx hardhat run scripts/sbtDeploy.js --network baobab @@ -342,29 +342,29 @@ npx hardhat run scripts/sbtDeploy.js --network baobab ![](/img/build/get-started/sbtDeploy.png) -**Step 4**: Open [Kaiascope](https://kairos.kaiascope.com/) to check if the SBT token has been deployed successfully. +**ステップ4**：[Kaiascope](https://kairos.kaiascope.com/) を開き、SBTトークンが正常にデプロイされたかどうかを確認します。 -**Step 5**: Copy and paste the deployed contract address in the search field and press Enter. You should see the recently deployed contract. +\*\*ステップ5配備された契約書アドレスを検索フィールドにコピー＆ペーストし、Enterキーを押します。 最近配備された契約が表示されるはずだ。 ![](/img/build/get-started/sbtKS.png) -## Hardhat Forking +## ハードハット・フォーク -Hardhat provides developers the functionality of simulating the mainnet (at any given block) to a local development network. One of the major benefit of this feature is that it enables developers to interact with deployed contract and also write test for complex cases. +Hardhatは、メインネット（任意のブロック）をローカル開発ネットワークにシミュレートする機能を開発者に提供します。 この機能の主な利点のひとつは、開発者がデプロイされたコントラクトとやりとりしたり、複雑なケースのテストを書いたりできるようになることだ。 -For this feature to work effectively, you need to connect to an archive node. You can read more about this feature [here](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks#forking-other-networks) +この機能を有効に使うには、アーカイブ・ノードに接続する必要がある。 この機能の詳細については[こちら](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks#forking-other-networks)をご覧ください。 -### Forking Mainnet +### フォーク・メインネット -Now that we have our Hardhat project set up let’s fork the Klaytn Mainnet using Hardhat. Open your terminal and run this command +Hardhatプロジェクトがセットアップできたので、Hardhatを使ってKaiaメインネットをフォークしてみよう。 ターミナルを開き、次のコマンドを実行する。 ```bash -npx hardhat node --fork +npx ハードハット・ノード --fork -npx hardhat node --fork https://archive-en.node.kaia.io +npx ハードハット・ノード --fork https://archive-en.node.kaia.io ``` -You can also configure `hardhat.config.js` - Hardhat Network to always do this: +また、`hardhat.config.js` - Hardhat Networkが常にこれを行うように設定することもできます： ``` networks: { @@ -376,35 +376,35 @@ networks: { } ``` -**Output** +**出力** ![](/img/build/get-started/hardhat-fork.png) -After successfully running this command, your terminal looks like the above image. You'll have 20 development accounts that are pre-funded with 10,000 test tokens. +このコマンドをうまく実行すると、ターミナルは上の画像のようになる。 10,000テストトークンで事前に資金調達された20の開発アカウントを持つことになる。 -The forked chain's RPC server is listening at `http://127.0.0.1:8545/`. You can verify the forked network by querying the latest block number. Let's try to make a cURL to the RPC to get the block number. Open a new terminal window and use the following command: +フォークされたチェーンのRPCサーバーは `http://127.0.0.1:8545/` で待ち受けている。 最新のブロック番号を照会することで、フォークされたネットワークを確認することができる。 ブロック番号を取得するために、RPCにcURLを作成してみよう。 新しいターミナル・ウィンドウを開き、以下のコマンドを使う： ```bash curl --data '{"method":"eth_blockNumber","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 ``` -**Output** +**出力** ![](/img/build/get-started/hardhat-fork-bn.png) -The output is an hexadecimal as seen above. To get the block number from the hex, convert the hex to a decimal using this [tool](https://www.rapidtables.com/convert/number/hex-to-decimal.html). You should get the latest block number from the time you forked the network. You can confirm the block number on [kaiascope](https://kaiascope.com/). +出力は上のように16進数である。 16進数からブロック番号を得るには、この[ツール](https://www.rapidtables.com/convert/number/hex-to-decimal.html)を使って16進数を10進数に変換する。 ネットワークをフォークした時点から最新のブロック番号を取得する必要がある。 ブロック番号は[kaiascope](https://kaiascope.com/)で確認できる。 -### Forking at a Block +### ブロックでのフォーク -With hardhat, you can fork the mainnet at a particular block. In that case, let’s fork the chain at block number `105701850`. +ハードハットを使えば、特定のブロックでメインネットをフォークできる。 その場合、ブロック番号`105701850`でチェーンをフォークしよう。 ```bash -npx hardhat node --fork --fork-block-number 105701850 +npx hardhat node --fork --fork-block-number 105701850 npx hardhat node --fork https://archive-en.node.kaia.io --fork-block-number 105701850 ``` -To confirm the forked chain at the stated block, open a new terminal window and use the following command: +指定されたブロックでフォークされたチェーンを確認するには、新しいターミナル・ウィンドウを開き、以下のコマンドを使用する： ```bash curl --data '{"method":"eth_blockNumber","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 @@ -412,6 +412,6 @@ curl --data '{"method":"eth_blockNumber","params":[],"id":1,"jsonrpc":"2.0"}' -H ![](/img/build/get-started/hardhat-fork-bnII.png) -The output returns hexadecimal which when converted using this [tool](https://www.rapidtables.com/convert/number/hex-to-decimal.html) should be equal to `105701850`. +出力は16進数を返し、この[ツール](https://www.rapidtables.com/convert/number/hex-to-decimal.html)を使って変換すると`105701850`に等しくなるはずである。 -For more in-depth guide on Hardhat, please refer to [Hardhat Docs](https://hardhat.org/hardhat-runner/docs/getting-started). Also, you can find the full implementation of the code for this guide on [GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/hardhat/soulbound-tokens) +Hardhatの詳細については、[Hardhat Docs](https://hardhat.org/hardhat-runner/docs/getting-started)を参照してください。 また、このガイドのコードの完全な実装は、[GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/hardhat/soulbound-tokens) にあります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/deploy.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/deploy.md index d94adfc47818..8dd1c907aeba 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/deploy.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/deploy.md @@ -1,16 +1,16 @@ -# Deploy Smart Contracts +# スマートコントラクトの導入 -There are various ways of deploying a smart contract on Klaytn. This document provides a step-by-step guide to deploy a sample contract using various tools. We assume that you have a Klaytn account with enough KLAY to pay the transaction fee. To create an account, you can use [Kaia Online Toolkit](https://toolkit.kaia.io/account/accountKeyLegacy)." +スマート・コントラクトをカイアにデプロイするには、さまざまな方法がある。 この文書では、さまざまなツールを使用してサンプル契約を展開するためのステップバイステップのガイドを提供します。 取引手数料を支払うのに十分なKAIAアカウントをお持ちであることを前提としています。 アカウントを作成するには、[Kaia Online Toolkit](https://toolkit.kaia.io/account/accountKeyLegacy)をご利用ください。" -## Remix Online IDE +## リミックス・オンラインIDE -Open your internet browser and go to [Kaia Plugin for Remix](https://ide.kaia.io). +インターネットブラウザを開き、[Kaia Plugin for Remix](https://ide.kaia.io)にアクセスします。 -1. Add a new file. +1. 新しいファイルを追加する。 ![](/img/build/smart-contracts/01_deployment_ide.png) -2. Copy and paste the following sample code (or any code you want to deploy) in the new file. The code consists of two contracts called Mortal and KlaytnGreeter, and it allows you to run a simple "Hello World!". +2. 以下のサンプルコード（または配置したいコード）をコピーして、新しいファイルに貼り付けます。 このコードはMortalとKaiaGreeterと呼ばれる2つのコントラクトで構成されており、シンプルな "Hello World!"を実行することができる。 ``` pragma solidity 0.5.12; @@ -24,7 +24,7 @@ contract Mortal { function kill() public payable { if (msg.sender == owner) selfdestruct(owner); } } -contract KlaytnGreeter is Mortal { +contract KaiaGreeter is Mortal { /* Define variable greeting of the type string */ string greeting; /* This runs when the contract is executed */ @@ -38,42 +38,42 @@ contract KlaytnGreeter is Mortal { } ``` -3. Select Compiler in the icon panel. Choose the desired EVM environment. For the Klaytn networks, you can choose between Baobab (testnet) and Cypress (mainnet). Click `Compile` when the sample code is ready to be complied before actual deployment. +3. アイコンパネルでコンパイラを選択します。 必要なEVM環境を選択します。 Kaiaネットワークでは、Kairos（テストネット）とMainnetのいずれかを選択できます。 実際のデプロイ前にサンプルコードをコンパイルする準備ができたら、`Compile`をクリックする。 ![](/img/build/smart-contracts/02_deployment_compile.png) -4. Now we can deploy the contract. Click on the Klaytn logo in the icon panel. Import an account by clicking the plus button next to `Account`. Make sure that the account has sufficient KLAY to pay for the transaction of deploying the smart contracts required. +4. これで契約を展開できる。 アイコンパネルのKaiaロゴをクリックします。 アカウント\`の横にあるプラスボタンをクリックしてアカウントをインポートします。 Make sure that the account has sufficient KLAY to pay for the transaction of deploying the smart contracts required. ![](/img/build/smart-contracts/05_deployment_account.png) -5. Set Gas limit and Value to send. +5. ガスリミットと送信する値を設定します。 -- You may need to set higher Gas limit if you are deploying a more complicated contract. In this example, you can leave it as it is. -- Set `Value` to 0 unless you want to send `KLAY` to the contract at the time of deployment. +- より複雑な契約を展開する場合は、ガス上限を高く設定する必要があるかもしれません。 この例では、そのままでいい。 +- デプロイ時にコントラクトに `KAIA` を送信したくない場合は `Value` を 0 に設定する。 -6. Enter "Hello World!" as an argument for constructor function and click on `Deploy` button. +6. コンストラクタ関数の引数に "Hello World!"を入力し、`Deploy`ボタンをクリックする。 ![](/img/build/smart-contracts/03_deployment_hello.png) -7. If the contract is successfully deployed, you will see the corresponding transaction receipt and detailed result in the terminal. +7. コントラクトが正常にデプロイされると、対応するトランザクションのレシートと詳細な結果がターミナルに表示されます。 -8. You can interact with the contract by clicking on the function buttons. The functions are represented in different colors. `constant` or `pure` functions in Solidity have blue bottons (`greet` in the example) and do not create a new transaction, so they don't cost any gas. Red buttons (`kill` in the example) represent `payable` functions that change the state on the blockchain, consume gas and can accept value. Orange buttons are for `non-payable` functions that change the contract state but do NOT accept a value. +8. 機能ボタンをクリックすることで、契約を操作することができます。 各機能は異なる色で表現されている。 Solidityの `constant` または `pure` 関数はブルーボトルを持ち（例では `greet`）、新しいトランザクションを作成しないので、ガソリンを消費しません。 赤いボタン（例では`kill`）は、ブロックチェーン上の状態を変更し、ガスを消費し、価値を受け入れることができる`支払い可能な`機能を表している。 オレンジ色のボタンは、契約状態を変更するが、値を受け付けない`non-payable`関数用です。 ![](/img/build/smart-contracts/06_deployment_functions.png) -For more details, please refer to this [link](../ide-and-tools/ide-and-tools.md). +詳しくはこちらの[リンク](../ide-and-tools/ide-and-tools.md)をご参照ください。 ## VVISP -vvisp is an easy-to-use CLI tool/framework for developing smart contracts, provided by HEACHI LABS. You can easily set environment, deploy and execute Klaytn smart contracts with a single command. Refer to the following link for more details. +vvispは、HEACHI LABSが提供する、スマートコントラクトを開発するための使いやすいCLIツール／フレームワークです。 Kaiaスマートコントラクトの環境設定、デプロイ、実行は1つのコマンドで簡単に行える。 詳細は以下のリンクを参照。 -- https\://henesis.gitbook.io/vvisp/deploying-smart-contracts +- https://henesis.gitbook.io/vvisp/deploying-smart-contracts ## solc & caver-js -Another way to deploy contracts is manually compiling contracts with solc and deploying them with caver-js. +コントラクトをデプロイするもう一つの方法は、solcでコントラクトを手動でコンパイルし、caver-jsでデプロイすることです。 -1. Create `KlaytnGreeter.sol` and write the following code. +1. `KaiaGreeter.sol`を作成し、以下のコードを記述する。 ``` pragma solidity 0.5.6; @@ -87,7 +87,7 @@ contract Mortal { function kill() public payable { if (msg.sender == owner) selfdestruct(owner); } } -contract KlaytnGreeter is Mortal { +contract KaiaGreeter is Mortal { /* Define variable greeting of the type string */ string greeting; /* This runs when the contract is executed */ @@ -101,25 +101,25 @@ contract KlaytnGreeter is Mortal { } ``` -2. Install solc 0.5.6. +2. solc 0.5.6をインストールする。 ``` $ sudo npm install -g solc@0.5.6 ``` -3. Compile the contract. +3. 契約書をまとめる。 ``` -$ solcjs KlaytnGreeter.sol --bin +$ solcjs KaiaGreeter.sol --bin ``` -4. Install caver-js. +4. caver-jsをインストールする。 ``` $ npm install caver-js. ``` -5. Create `deploy.js` in the same directory with the following code. +5. 同じディレクトリに以下のコードで `deploy.js` を作成する。 ``` const Caver = require("caver-js"); @@ -151,9 +151,9 @@ caver.kaia.sendTransaction({ }) ``` -_NOTE_: This example is not recommended for production use. Be very careful when dealing with private keys. +_NOTE_: This example is not recommended for production use. 秘密鍵の取り扱いには十分注意すること。 -6. Deploy the contract using node environment. +6. ノード環境を使ってコントラクトをデプロイする。 ``` $ node deploy.js diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/foundry.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/foundry.md index 29184115190d..3067191b8b49 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/foundry.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/foundry.md @@ -1,73 +1,73 @@ -# Deploy smart contract using Foundry +# Foundryを使用してスマートコントラクトをデプロイする ![](/img/banners/kaia-foundry.png) -## Introduction +## はじめに -Foundry is a smart contract development framework written in Rust that enables developers to manage and compile contracts, run tests, deploy contracts, and interact with the network from the command line via solidity scripts. +FoundryはRustで書かれたスマートコントラクト開発フレームワークで、開発者はコマンドラインからsolidityスクリプトを使ってコントラクトの管理とコンパイル、テストの実行、コントラクトのデプロイ、ネットワークとのやり取りができる。 -Foundry consists of four main CLI tools that allow for fast and modular smart contract development, namely: +Foundryは、高速でモジュール化されたスマート・コントラクト開発を可能にする4つの主要CLIツールで構成されている： -- [Forge](https://github.com/foundry-rs/foundry/tree/master/forge): You can deploy, test, and compile smart contracts using Forge. -- [Cast](https://github.com/foundry-rs/foundry/tree/master/cast): Cast has made it simple to interact with EVM smart contracts. This includes obtaining chain data, sending transactions, and other things. -- [Anvil](https://github.com/foundry-rs/foundry/tree/master/anvil): Do you need to spin up a local node? Anvil is a local node environment offered by Foundry. -- [Chisel](https://github.com/foundry-rs/foundry/blob/master/chisel): Fast, useful, and verbose solidity REPL. +- [Forge](https://github.com/foundry-rs/foundry/tree/master/forge)： Forgeを使ってスマートコントラクトのデプロイ、テスト、コンパイルができる。 +- [Cast](https://github.com/foundry-rs/foundry/tree/master/cast)：CastはEVMスマートコントラクトとのやり取りを簡単にした。 これには、チェーンデータの取得、トランザクションの送信などが含まれる。 +- [Anvil](https://github.com/foundry-rs/foundry/tree/master/anvil)：ローカルノードをスピンアップする必要がありますか？ AnvilはFoundryが提供するローカルノード環境である。 +- [Chisel](https://github.com/foundry-rs/foundry/blob/master/chisel)：高速で便利で冗長なsolidity REPL。 -In this guide, you will: +このガイドでは、次のことを説明する： -- Create a simple foundry project. -- Compile and test a sample smart contract using Foundry. -- Deploy smart contracts using Foundry to the Klaytn Baobab Network. -- Explore forking mainnet with cast and anvil. +- 簡単な鋳造プロジェクトを立ち上げる。 +- Foundryを使用してスマート・コントラクトのサンプルをコンパイルし、テストします。 +- Foundryを使用してスマートコントラクトをKaia Kairosネットワークにデプロイします。 +- キャストとアンビルでメインネットをフォークする。 -## Pre-requisites +## 前提条件 -To follow this tutorial, the following are the prerequisites: +このチュートリアルに従うには、次のことが前提条件となる： - Code editor: a source-code editor such [VS-Code](https://code.visualstudio.com/download). -- [MetaMask](../../tutorials/connecting-metamask.mdx#install-metamask): used to deploy the contracts, sign transactions and interact with the contracts. -- RPC Endpoint: you can get this from one of the supported [endpoint providers](../../../references/public-en.md). -- Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. -- Install [Rust](https://www.rust-lang.org/tools/install) and [Foundry](https://github.com/foundry-rs/foundry#installation). +- [MetaMask](../../tutorials/connecting-metamask.mdx#install-metamask)：コントラクトのデプロイ、トランザクションへの署名、コントラクトとの対話に使用される。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](../../../references/public-en.md)の1つから取得できます。 +- [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 +- [Rust](https://www.rust-lang.org/tools/install)と[Foundry](https://github.com/foundry-rs/foundry#installation)をインストールする。 -## Setting Up Your Development Environment +## 開発環境のセットアップ -To check if your foundry installation was successful, run the command below: +ファウンドリのインストールが成功したかどうかを確認するには、以下のコマンドを実行してください： ```bash forge -V ``` -**Output** +**出力** ![](/img/build/get-started/forge-version.png) -After successfully installing foundry, you now have access to the CLI tools (forge, cast, anvil, chisel) available in foundry. Let's set up a foundry project in the following steps: +foundryのインストールに成功すると、foundryで使用できるCLIツール（forge、cast、anvil、chisel）にアクセスできるようになります。 次のステップでファウンドリー・プロジェクトをセットアップしてみよう： -**Step 1**: To start a new project, run the command below: +\*\*ステップ1新しいプロジェクトを開始するには、以下のコマンドを実行します： ```bash forge init foundry_example ``` -**Step 2**: Navigate into your project folder. +**ステップ 2**：プロジェクトフォルダに移動します。 ```bash cd foundry_example ls ``` -After initializing a foundry project, your current directory should include: +ファウンドリー・プロジェクトを初期化した後、カレント・ディレクトリーには以下が含まれているはずだ： -- **src**: the default directory for your smart contracts. -- **tests**: the default directory for tests. -- **foundry.toml**: the default project configuration file. -- **lib**: the default directory for project dependencies. -- **script**: the default directory for solidity scripting files. +- **src**：スマートコントラクトのデフォルトディレクトリ。 +- **tests**：テスト用のデフォルト・ディレクトリ。 +- **foundry.toml**：デフォルトのプロジェクト設定ファイル。 +- **lib**: プロジェクトの依存関係のデフォルト・ディレクトリ。 +- **script**：solidityスクリプトファイルのデフォルトディレクトリです。 -## Sample smart contract +## スマート・コントラクトのサンプル -In this section, we will be using the sample counter contract in the initialized foundry project. The `counter.sol` file in the `src/` folder should look like this: +このセクションでは、初期化されたファウンドリー・プロジェクトのサンプル・カウンター契約を使用する。 `src/`フォルダにある`counter.sol`ファイルは以下のようになるはずだ： ```solidity // SPDX-License-Identifier: UNLICENSED @@ -83,13 +83,13 @@ contract Counter { } ``` -**Code Walkthrough** +\*\*コード・チュートリアル -This is your smart contract. **Line 1** shows it uses the Solidity version 0.8.13 or greater. From **lines 4-12**, a smart contract `Counter` is created. This contract simply stores a new number using the **setNumber** function and increments it by calling the **increment** function. +これがスマート・コントラクトだ。 **行1**は、Solidityバージョン0.8.13以上を使用していることを示しています。 4-12行目から\*\*、スマート・コントラクト `Counter` が作成される。 このコントラクトは、単純に**setNumber**関数を使用して新しい数値を格納し、**increment**関数を呼び出してその数値をインクリメントする。 -## Testing smart contract +## スマートコントラクトのテスト -Foundry allows us to write tests in solidity as opposed to writing tests in javascript in other smart contract development frameworks. In our initialized foundry project, the `test/Counter.t.sol` is an example of a test written in solidity. The code looks like this: +Foundry allows us to write tests in solidity as opposed to writing tests in javascript in other smart contract development frameworks. 初期化されたfoundryプロジェクトでは、`test/Counter.t.sol`がsolidityで書かれたテストの例です。 コードは次のようになる： ```solidity // SPDX-License-Identifier: UNLICENSED @@ -113,144 +113,144 @@ contract CounterTest is Test { } ``` -The code above shows you imported forge standard library and Counter.sol. +上のコードでは、forge標準ライブラリとCounter.solをインポートしています。 -The tests above check the following: +上記のテストは以下のことをチェックする： -- Is the number increasing? -- Is the number equal to the set number? +- その数は増えているのか？ +- 数字は設定された数字と等しいか？ -To check if your test works fine, run the following command: +テストがうまくいくかどうかを確認するには、以下のコマンドを実行する： ```bash forge test ``` -**Output** +**出力** ![](/img/build/get-started/forge-test.png) -To learn more about writing tests, advanced testing, and other features, refer to [Foundry's documentation](https://book.getfoundry.sh/forge/tests). +テストの書き方や高度なテスト、その他の機能については、[Foundryのドキュメント](https://book.getfoundry.sh/forge/tests)を参照してください。 -## Compiling your contracts +## 契約書の作成 -Compile your contract with this command: +このコマンドで契約書をコンパイルする： ```bash forge build ``` -## Deploying your contracts +## 契約の展開 -To deploy a contract using foundry, you must provide an RPC URL and a private key of the account that will deploy the contract. Take a look at the list of [rpc-providers](../../../references/public-en.md) on Kaia to find your rpc-url, and create an account using [MetaMask](../../tutorials/connecting-metamask.mdx#install-metamask). +ファウンドリを使用してコントラクトをデプロイするには、RPC URLと、コントラクトをデプロイするアカウントの秘密鍵を提供する必要があります。 Kaiaの[rpc-providers](../../../references/public-en.md)のリストを見て、あなたのrpc-urlを見つけ、[MetaMask](../../tutorials/connecting-metamask.mdx#install-metamask)を使ってアカウントを作成してください。 -**Step 1**: To deploy your contract to the Klaytn Baobab network, run the command below: +**ステップ1**: 契約をカイア・カイロス・ネットワークに展開するには、以下のコマンドを実行します。 ```bash $ forge create --rpc-url --private-key src/Counter.sol:Counter ``` -**Example** +**例** ```bash -forge create --rpc-url https://public-en-kairos.node.kaia.io --private-key hhdhdhdhprivatekeyhdhdhdhud src/Counter.sol:Counter +forge create --rpc-url https://public-en-kairos.node.kaia.io --private-key hhdhdhprivatekey hhdhdhud src/Counter.sol:Counter ``` -**WARNING: Replace the private key argument with your private key from MetaMask. Be very careful not to expose your private key.** +**警告**：引数の秘密鍵は、MetaMaskの秘密鍵に置き換えてください。 秘密鍵を公開しないよう、十分注意してください。 -**Output** +**出力** ![](/img/build/get-started/foundry-create.png) -**Step 2**: Open [Kaiascope](https://kairos.kaiascope.com/tx/0x669e39c9661fdab59aa34989b58b3f89376a93f846a0c71d2858918f58a307e2?tabId=internalTx) to check if the counter contract deployed successfully. +**ステップ2**:[Kaiascope](https://kairos.kaiascope.com/tx/0x83c8b55f3fd90110f9b83cd20df2b2bed76cfeb42447725af2d60b2885f479d3?tabId=internalTx) を開き、カウンター契約が正常にデプロイされたかチェックする。 -**Step 3**: Copy and paste the transaction hash in the search field and press Enter. You should see the recently deployed contract. +**ステップ 3**：取引ハッシュをコピーして検索フィールドに貼り付け、Enterキーを押します。 最近配備された契約が表示されるはずだ。 ![](/img/build/get-started/forge-scope.png) -## Interacting with the contract +## 契約とのやり取り -After successfully deploying your smart contract, you will want to call and execute functions right. Let's get to interact with the deployed contracts on Klaytn Baobab Network using [Cast](https://book.getfoundry.sh/reference/cast/cast-send.html). In this section, you will learn how to use the [cast call](https://book.getfoundry.sh/reference/cast/cast-call) to execute the `read-only` function and [cast send](https://book.getfoundry.sh/reference/cast/cast-send) to execute `write` functions. +スマート・コントラクトのデプロイに成功したら、関数を正しく呼び出して実行したいだろう。 [Cast](https://book.getfoundry.sh/reference/cast/cast-send.html) を使って、Kaia Kairos Networkに配備されたコントラクトとやりとりしてみましょう。 このセクションでは、[cast call](https://book.getfoundry.sh/reference/cast/cast-call) を使って `read-only` 関数を実行し、[cast send](https://book.getfoundry.sh/reference/cast/cast-send) を使って `write` 関数を実行する方法を学びます。 -**A. cast call**: To get the number stored in the contract, you will be calling the `number` function. Run the command below to see this in action. +**A. cast call**：コントラクトに格納されている数字を取得するには、`number`関数を呼び出します。 以下のコマンドを実行し、その動きを見てみよう。 ```bash cast call YOUR_CONTRACT_ADDRESS "number()" --rpc-url RPC-API-ENDPOINT-HERE ``` -**Example** +**例** ```bash cast call 0xe4d576c447733da7ca9197e88d34a74c3c865cff "number()" --rpc-url https://public-en-kairos.node.kaia.io ``` -**Output** +**出力** ![](/img/build/get-started/cast-call-number.png) -You should get this data in hexadecimal format: +このデータを16進数で取得してください： ```bash 0x0000000000000000000000000000000000000000000000000000000000000000 ``` -However to get your desired result, use cast to convert the above result. In this case, the data is a number, so you can convert it into base 10 to get the result 0: +しかし、希望する結果を得るには、上記の結果をキャストで変換する。 この場合、データは数字なので、10進数に変換すれば結果は0になる： ```bash cast --to-base 0x0000000000000000000000000000000000000000000000000000000000000000 10 ``` -**Output** +**出力** ![](/img/build/get-started/cast-call-0.png) -**B. cast send**: To sign and publish a transaction such as executing a `setNumber` function in the counter contract, run the command below: +**B. cast send**：カウンターのコントラクトで `setNumber` 関数を実行するようなトランザクションに署名して発行するには、以下のコマンドを実行する： ```bash cast send --rpc-url= “setNumber(uint256)” arg --private-key= ``` -**Example** +**例** ```bash cast send --rpc-url=https://public-en-kairos.node.kaia.io 0xe4d576c447733da7ca9197e88d34a74c3c865cff "setNumber(uint256)" 10 --private-key= ``` -**Output** +**出力** ![](/img/build/get-started/cast-send-setNum.png) -**Crosscheck Number** +**クロスチェック番号** ```bash cast call 0xe4d576c447733da7ca9197e88d34a74c3c865cff "number()" --rpc-url https://public-en-kairos.node.kaia.io ``` -**Output** +**出力** ![](/img/build/get-started/cast-call-10.png) -You should get this data in hexadecimal format: +このデータを16進数で取得してください： ```bash 0x000000000000000000000000000000000000000000000000000000000000000a ``` -However to get your desired result, use cast to convert the above result. In this case, the data is a number, so you can convert it into base 10 to get the result 10: +しかし、希望する結果を得るには、上記の結果をキャストで変換する。 この場合、データは数字なので、それを基数10に変換して、結果10を得ることができる： ```bash cast --to-base 0x000000000000000000000000000000000000000000000000000000000000000a 10 ``` -**Output** +**出力** ![](/img/build/get-started/cast-call-result-10.png) -## Forking Mainnet with Cast and Anvil +## キャストとアンヴィルによるメインネットのフォーク -Foundry allows us to fork the mainnet to a local development network ([Anvil](https://book.getfoundry.sh/reference/anvil/)). Also, you can interact and test with contracts on a real network using [Cast](https://book.getfoundry.sh/reference/cast/). +Foundryでは、メインネットをローカル開発ネットワーク（[Anvil](https://book.getfoundry.sh/reference/anvil/)）にフォークすることができる。 また、[Cast](https://book.getfoundry.sh/reference/cast/)を使って、実際のネットワーク上でコントラクトと対話し、テストすることができます。 -### Getting Started +### はじめに Now that you have your Foundry project up and running, you can fork the mainnet (cypress) by running the command below: @@ -258,35 +258,35 @@ Now that you have your Foundry project up and running, you can fork the mainnet anvil --fork-url rpc-url ``` -**Example** +**例** ```bash anvil --fork-url https://archive-en.node.kaia.io ``` -**Output** +**出力** ![](/img/build/get-started/anvil-localnode.png) -After successfully running this command, your terminal looks like the above image. You'll have 10 accounts created with their public and private keys as well 10,000 prefunded tokens. The forked chain's RPC server is listening at `127.0.0.1:8545`. +このコマンドをうまく実行すると、ターミナルは上の画像のようになる。 10,000トークンと公開鍵、秘密鍵で10アカウントが作成されます。 フォークされたチェーンの RPC サーバーは `127.0.0.1:8545` で待ち受けている。 -To verify you have forked the network, you can query the latest block number: +ネットワークをフォークしたことを確認するには、最新のブロック番号を照会することができる： ```bash curl --data '{"method":"eth_blockNumber","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 ``` -You can convert the result from the task above using [hex to decimal](https://www.rapidtables.com/convert/number/hex-to-decimal.html). You should get the latest block number from the time you forked the network. To verify this, cross-reference the block number on [Kaiascope](https://kaiascope.com/block/118704896?tabId=txList). +上記のタスクの結果は、[16進数から10進数](https://www.rapidtables.com/convert/number/hex-to-decimal.html)を使って変換できる。 ネットワークをフォークした時点から最新のブロック番号を取得する必要がある。 これを確認するには、[Kaiascope](https://kaiascope.com/block/118704896?tabId=txList)のブロック番号をクロスリファレンスする。 -### Illustration +### イラスト -In this section, you will learn how to transfer oUSDC tokens from someone who holds oUSDC to an account created by Anvil (0x70997970C51812dc3A010C7d01b50e0d17dc79C8 - Bob) +このセクションでは、oUSDC を保持している誰かから Anvil が作成したアカウントに oUSDC トークンを転送する方法について説明します (0x70997970C51812dc3A010C7d01b50e0d17dc79C8 - Bob) -**Transferring oUSDC** +**OUSDC**を譲渡する。 -Go to Klaytnscope and search for holders of oUSDC tokens (here). Let's pick a random account. In this example, we will be using `0x8e61241e0525bd45cfc43dd7ba0229b422545bca`. +Kaiascopeに行き、oUSDCトークンの保有者を検索する（ここ）。 ランダムにアカウントを選んでみよう。 この例では、`0x8e61241e0525bd45cfc43dd7ba0229b422545bca`を使用する。 -Let's export our contracts and accounts as environment variables: +契約とアカウントを環境変数としてエクスポートしよう： ```bash export BOB=0x70997970C51812dc3A010C7d01b50e0d17dc79C8 @@ -294,7 +294,7 @@ export oUSDC=0x754288077d0ff82af7a5317c7cb8c444d421d103 export oUSDCHolder=0x8e61241e0525bd45cfc43dd7ba0229b422545bca ``` -We can check Bob’s balance using cast call: +キャストコールを使ってボブの残高をチェックできる： ```bash cast call $oUSDC \ @@ -302,11 +302,11 @@ cast call $oUSDC \ $BOB ``` -**Output** +**出力** ![](/img/build/get-started/oUsdcBob4.png) -Similarly, we can also check our oUSDC holder’s balance using cast call: +同様に、キャスト・コールを使ってoUSDCホルダーの残高をチェックすることもできる： ```bash cast call $oUSDC \ @@ -314,11 +314,11 @@ cast call $oUSDC \ $oUSDCHolder ``` -**Output** +**出力** ![](/img/build/get-started/oUsdcHolder4.png) -Let's transfer some tokens from the lucky user to Alice using cast send: +幸運なユーザーからアリスへ、キャスト送信を使ってトークンを転送してみましょう： ````bash cast rpc anvil_impersonateAccount $oUSDCHolder @@ -331,11 +331,11 @@ cast send $oUSDC \ ```0000 ```` -**Output** +**出力** ![](/img/build/get-started/cast-send.png) -Let's check that the transfer worked: +転送がうまくいったか確認してみよう： ```bash cast call $oUSDC \ @@ -343,7 +343,7 @@ cast call $oUSDC \ $BOB ``` -**Output** +**出力** ![](/img/build/get-started/oUsdcBobAfter.png) @@ -353,8 +353,8 @@ cast call $oUSDC \ $oUSDCHolder ``` -**Output** +**出力** ![](/img/build/get-started/oUsdcHolderAfter.png) -For more in-depth guide on foundry, please refer to [Foundry Docs](https://book.getfoundry.sh/). Also, you can find the full implementation of the code for this guide on [GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/foundry). +ファウンドリーに関するより詳細なガイドについては、[ファウンドリードキュメント](https://book.getfoundry.sh/)を参照してください。 また、このガイドのコードの完全な実装は[GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/foundry)にあります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/private-network.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/private-network.md index e4a92d503f22..85a111fcbb5e 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/private-network.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/private-network.md @@ -1,49 +1,49 @@ -# Deploying smart contract using Private Network +# プライベートネットワークを使用したスマートコントラクトの展開 -## Introduction +## はじめに -In this guide, we will walk you through the process of deploying a Greeter contract on a private Kaia network using [Kaia Hardhat Utils](https://github.com/ayo-klaytn/hardhat-utils). By following this guide, you'll learn how to: +このガイドでは、[Kaia Hardhat Utils](https://github.com/ayo-klaytn/hardhat-utils) を使用して、プライベート Kaia ネットワーク上に Greeter 契約をデプロイする手順を説明します。 このガイドに従うことで、その方法を学ぶことができる： -- Set up a Hardhat project. -- Launch a private network simulating the Kairos Testnet. -- Utilize Hardhat utils to deploy smart contracts on this private network. +- ハードハット・プロジェクトを立ち上げる。 +- Kairos Testnetをシミュレートしたプライベートネットワークを立ち上げる。 +- Hardhatユーティリティを利用して、このプライベート・ネットワーク上にスマート・コントラクトをデプロイする。 -## Prerequisite +## 前提条件 -To follow this tutorial, the following are the prerequisites: +このチュートリアルに従うには、次のことが前提条件となる： -- Code editor: a source-code editor such as [VS Code](https://code.visualstudio.com/download). -- Docker: if you don’t have docker installed, kindly install using this [link](https://docs.docker.com/desktop/) -- [Node.js and npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm): Node version 18 and above. +- コードエディタ：[VS Code](https://code.visualstudio.com/download)などのソースコードエディタ。 +- Docker: dockerがインストールされていない場合は、こちらの[リンク](https://docs.docker.com/desktop/)からインストールしてください。 +- [Node.jsとnpm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)：Node バージョン 18 以上。 -## Setting Up your Development Environment +## 開発環境のセットアップ -In this section, we will install hardhat, Kaia hardhat utils and other necessary dependencies needed for bootstrapping our project. +このセクションでは、hardhat、Kaia hardhat utils、その他プロジェクトのブートストラップに必要な依存関係をインストールする。 -**Step 1: Create a project directory** +**ステップ1：プロジェクト・ディレクトリを作成する**。 ```js mkdir $HOME/kaia-greeter cd kaia-greeter ``` -**Step 2: Initialize an npm project** +**ステップ2: npmプロジェクトの初期化**. ```js npm init -y ``` -**Step 3: Install hardhat, hardhat-utils and other dependencies** +**ステップ3: hardhat、hardhat-utils、その他の依存関係をインストールする**。 -- Copy and paste the code below in your terminal to install hardhat and hardhat-utils +- 以下のコードをターミナルにコピー＆ペーストして、hardhatとhardhat-utilsをインストールする。 ```js npm i hardhat @klaytn/hardhat-utils ``` -- Copy and paste the code below to install other dependencies +- 他の依存関係をインストールするには、以下のコードをコピー＆ペーストしてください。 ```js npm install @nomiclabs/hardhat-ethers hardhat-deploy dotenv @@ -51,13 +51,13 @@ npm install @nomiclabs/hardhat-ethers hardhat-deploy dotenv :::note -The hardhat-utils plugin depends on [hardhat-ethers](https://www.npmjs.com/package/@nomiclabs/hardhat-ethers) and [hardhat-deploy](https://www.npmjs.com/package/hardhat-deploy) plugin. Make sure to require or import them in your `hardhat.config.js` or `hardhat.config.ts`. +hardhat-utils プラグインは [hardhat-ethers](https://www.npmjs.com/package/@nomiclabs/hardhat-ethers) と [hardhat-deploy](https://www.npmjs.com/package/hardhat-deploy) プラグインに依存しています。 `hardhat.config.js`または`hardhat.config.ts`で、これらをrequireまたはimportしてください。 ::: :::info -(Recommended) Install hardhat shorthand. But you can still use the tasks with npx hardhat. +(推奨）ハードハットの速記をインストールする。 しかし、npxのハードハットでもタスクは可能だ。 ```js npm install hardhat-shorthand --save @@ -65,58 +65,58 @@ npm install hardhat-shorthand --save ::: -**Step 4: Initialize a hardhat project** +**ステップ4：ハードハット・プロジェクトを初期化する**。 -Run the command below to initiate an hardhat project: +以下のコマンドを実行して、ハードハット・プロジェクトを開始する： ```js -npx hardhat init +npxハードハット ``` -For this guide, you'll be selecting "create an empty hardhat.config.js" project as seen below: +このガイドでは、以下のように「空のhardhat.config.jsを作成する」プロジェクトを選択する： ```js -888 888 888 888 888 -888 888 888 888 888 -8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 -888 888 "88b 888P" d88" 888 888 "88b "88b 888 -888 888 .d888888 888 888 888 888 888 .d888888 888 -888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. -888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 -👷 Welcome to Hardhat v2.22.9 👷‍ -? What do you want to do? … - Create a JavaScript project - Create a TypeScript project - Create a TypeScript project (with Viem) -❯ Create an empty hardhat.config.js - Quit +888 888 888 +888 888 888 +88888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 +888 888 "88b 888P" d88" 888 888 "88b "88b 888 +888 888 .d888888 888 888 .d888888 888 +888 888 888 888 Y88b 888 888 Y88b. +888 888 "Y88888 888 888 "Y88888 +👷 ようこそHardhat v2.22.9 👷‍ +?何をしたいのですか？ … + JavaScriptプロジェクトを作成する + TypeScriptプロジェクトを作成する + TypeScriptプロジェクトを作成する(Viemを使用) +❯ 空のhardhat.config.jsを作成する + 終了する ``` -**Step 5: Create a .env file** +**ステップ5：.envファイルを作成する**。 -Now create your `.env` file in the project folder. This file helps us load environment variables from an `.env` file into process.env. +プロジェクトフォルダーに `.env` ファイルを作成する。 このファイルは、`.env`ファイルからprocess.envに環境変数をロードするのに役立つ。 -Copy and paste this command in your terminal to create a `.env` file +以下のコマンドをターミナルにコピー＆ペーストして、`.env` ファイルを作成する。 ```js -touch .env +タッチ.env ``` -Configure your .env file to look like this: +.envファイルを次のように設定する： ``` -PRIVATE_KEY="COPY & PASTE ANY OF THE PRIVATE KEY PROVIDED BY LOCAL PRIVATE NETWORK" +private_key="ローカル・プライベート・ネットワークから提供された秘密鍵のコピー＆ペースト" ``` :::note -When you launch the private network in the next section, you will be able to access the private key provided by the local network. +次のセクションでプライベート・ネットワークを起動すると、ローカル・ネットワークが提供する秘密鍵にアクセスできるようになる。 ::: -**Step 6: Setup Hardhat Configs** +**ステップ6: ハードハット設定の設定**」。 -Modify your `hardhat.config.js` with the following configurations: +以下の設定で `hardhat.config.js` を修正する： ```js require("@nomiclabs/hardhat-ethers"); @@ -153,9 +153,9 @@ module.exports = { }; ``` -## Launching the Private Network +## プライベートネットワークの立ち上げ -To launch a private network, the hardhat utils plugin provides us a task to easily launch one viz: +プライベート・ネットワークを立ち上げるために、hardhat utilsプラグインは簡単に立ち上げるタスクを提供してくれる： ```js hh klaytn-node @@ -163,9 +163,9 @@ hh klaytn-node ![](/img/build/smart-contracts/pn-run-node.png) -## Attaching Console +## コンソールの取り付け -The private network comes with a JavaScript console. From the console command line, you can initiate part of Kaia API calls to your network. To attach to the JavaScript console, execute the following command: +プライベート・ネットワークにはJavaScriptのコンソールが付属している。 コンソールのコマンドラインから、ネットワークへのKaia APIコールの一部を開始することができます。 JavaScriptコンソールに接続するには、以下のコマンドを実行する： ```js hh klaytn-node --attach @@ -180,15 +180,15 @@ Welcome to the Kaia JavaScript console! :::note -Type **kaia** or **personal** to get the list of available functions. +**kaia**または**personal**と入力すると、利用可能な機能のリストが表示されます。 ::: -## Checking the Balance in your account +## 口座残高の確認 -When we launched the private network, it provided us with a list of accounts, private key and pre-funded values for each account. +プライベート・ネットワークを立ち上げると、アカウントのリスト、秘密鍵、各アカウントの事前入金額が提供された。 -To see the balance of the account, execute the following command. +口座の残高を見るには、以下のコマンドを実行する。 ```js kaia.getBalance("0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266") @@ -196,9 +196,9 @@ kaia.getBalance("0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266") ![](/img/build/smart-contracts/pn-check-balance.png) -## Configuring hardhat network environment +## ハードハット・ネットワーク環境の設定 -Now that we are running a stand alone local network, which external clients (wallets, dApp) can connect to, we need to configure hardhat to use this network by running this command: +外部クライアント（ウォレットやdApp）が接続できるスタンドアローン・ローカル・ネットワークが稼働しているので、このコマンドを実行して、ハードハットがこのネットワークを使用するように設定する必要がある： ```js export HARDHAT_NETWORK=localhost @@ -211,13 +211,13 @@ hh --network localhost accounts ![](/img/build/smart-contracts/pn-lh-accounts.png) -## Creating KaiaGreeter Smart Contract +## KaiaGreeterスマートコントラクトの作成 -In this section, you will create a KaiaGreeter smart contract. +このセクションでは、KaiaGreeterスマート・コントラクトを作成する。 -**Step 1:** Create a new folder named **contracts** folder in the Explorer pane, click the New File button and create a new file named `KaiaGreeter.sol` +**ステップ1：** エクスプローラーペインに**contracts**フォルダという新しいフォルダを作成し、新規ファイルボタンをクリックし、`KaiaGreeter.sol`という名前の新規ファイルを作成します。 -**Step 2:** Open the file and paste the following code: +\*\*ステップ2：\*\*ファイルを開き、以下のコードを貼り付ける： ```js // SPDX-License-Identifier: UNLICENSED @@ -239,13 +239,13 @@ contract KaiaGreeter { } ``` -## Deploying KaiaGreeter +## KaiaGreeterを展開する -In this section we will use the hardhat-deploy plugin to deploy our contracts. +このセクションでは、hardhat-deployプラグインを使ってコントラクトをデプロイする。 -**Step 1:** In the Explorer pane, Create a new folder called **deploy** and click the New File button to create a new file named `deploy.js`. +**ステップ1:** エクスプローラーペインで、**deploy** という新しいフォルダーを作成し、新規ファイルボタンをクリックして `deploy.js` という名前の新規ファイルを作成します。 -**Step 2:** Copy and paste the following code inside the file. +\*\*ステップ2：\*\*以下のコードをコピーし、ファイル内に貼り付ける。 ```js module.exports = async ({getNamedAccounts, deployments}) => { @@ -260,93 +260,93 @@ module.exports = async ({getNamedAccounts, deployments}) => { module.exports.tags = ['KaiaGreeter']; ``` -**Step 3:** In the terminal, run the following command which tells Hardhat to deploy your KaiaGreeter contract on the private network. +\*\*ターミナルで、以下のコマンドを実行し、Hardhatにプライベートネットワーク上にKaiaGreeter契約を展開するように指示します。 ```js -hh deploy +hh 配備 ``` ![](/img/build/smart-contracts/pn-deployed-tx.png) -## Verifying transaction using Block Explorer +## ブロックエクスプローラを使用したトランザクションの検証 -**Step 1:** To verify our transactions using a local blockscout explorer, run the command below in a new terminal: +\*\*ステップ1：ローカルのblockscoutエクスプローラーを使用してトランザクションを検証するには、新しいターミナルで以下のコマンドを実行します： ```js -hh explorer --network localhost +hhエクスプローラ --ネットワーク localhost ``` ```js -[+] Using env: { - DOCKER_RPC_HTTP_URL: 'http://host.docker.internal:8545/', +[+] env: { + DOCKER_RPC_HTTP_URL：'http://host.docker.internal:8545/', DOCKER_LISTEN: '0.0.0.0:4000', DOCKER_DISABLE_TRACER: 'false', DOCKER_DEBUG: '0' -} -[+] Open in the browser: http://localhost:4000 - Network blockscout_default Creating - Network blockscout_default Created - Container blockscout-db-1 Creating - Container blockscout-frontend-1 Creating - Container blockscout-smart-contract-verifier-1 Creating - Container blockscout-redis_db-1 Creating - Container blockscout-smart-contract-verifier-1 Created - Container blockscout-db-1 Created - Container blockscout-frontend-1 Created - Container blockscout-redis_db-1 Created - Container blockscout-backend-1 Creating - Container blockscout-backend-1 Created - Container blockscout-frontend-1 Starting - Container blockscout-redis_db-1 Starting - Container blockscout-smart-contract-verifier-1 Starting - Container blockscout-db-1 Starting - Container blockscout-db-1 Started - Container blockscout-redis_db-1 Started - Container blockscout-smart-contract-verifier-1 Started - Container blockscout-backend-1 Starting - Container blockscout-frontend-1 Started - Container blockscout-backend-1 Started +}. +[+] ブラウザで開く: http://localhost：4000 + Network blockscout_default 作成 + Network blockscout_default 作成 + Container blockscout-db-1 作成 + Container blockscout-frontend-1 作成 + Container blockscout-smart-contract-verifier-1 作成 + Container blockscout-redis_db-1 作成 + blockscout-smart-contract-verifier-1 作成 + コンテナ blockscout-db-1 作成 + コンテナ blockscout-frontend-1 作成 + コンテナ blockscout-redis_db-1 作成 + コンテナ blockscout-backend-1 作成 + コンテナ blockscout-backend-1 作成 + コンテナ blockscout-frontend-1 開始 + コンテナ blockscout-redis_db-1 開始 + コンテナ blockscout-smart-contract-verifier-1 開始 + コンテナ blockscout-db-1 開始 + コンテナ blockscout-db-1 の開始 + コンテナ blockscout-redis_db-1 の開始 + コンテナ blockscout-smart-contract-verifier-1 の開始 + コンテナ blockscout-backend-1 の開始 + コンテナ blockscout-frontend-1 の開始 + コンテナ blockscout-backend-1 の開始 ``` -**Step 2:** To access this block explorer, open up [http://localhost:4000](http://localhost:4000) in your browser. +**ステップ2：** このブロック・エクスプローラーにアクセスするには、ブラウザで [http://localhost:4000](http://localhost:4000) を開いてください。 -Step 3: Copy and paste the deployed contract address in the search field and press Enter. You should see the recently deployed contract. +ステップ 3: 配備された契約書アドレスを検索フィールドにコピー＆ペーストし、Enterキーを押します。 最近配備された契約が表示されるはずだ。 ![](/img/build/smart-contracts/pn-verify-tx-block-explorer.png) -## Interacting with deployed contract +## 配備された契約とのやり取り -### using hardhat utils contract task +### ハードハットユーティル契約タスクの使用 -1. To call a read-only function of the deployed contract, run the command below: +1. デプロイされたコントラクトの読み取り専用関数を呼び出すには、以下のコマンドを実行する： ```js -hh call KaiaGreeter getTotalGreetings +hh call カイアグリーター getTotalGreetings ``` ![](/img/build/smart-contracts/pn-read-function.png) -2. To send a function invoking transaction to the deployed contract, run the command below: +2. 関数を呼び出すトランザクションをデプロイされたコントラクトに送信するには、以下のコマンドを実行する： ```js -hh send KaiaGreeter greet +カイアグリーターに挨拶を送る ``` ```jsx title="Result Result " -sent KaiaGreeter#greet (tx: 0xc0bd25ffb594c13d5ae1f77f7eb02f2978013c69f9f6e22694b76fa26c329e85)...ok (block 2837, gas used: 47457) +KaiaGreeter#greetを送信 (tx: 0xc0bd25ffb594c13d5ae1f77f7eb02f2978013c69f9f6e22694b76fa26c329e85)...OK (ブロック 2837、使用ガス数: 47457) ``` -### using Kaia SDK +### カイアSDKを使用 -**Step 1:** To interact with the deployed contract using [Kaia SDK](https://github.com/kaiachain/kaia-sdk), you need to install Kaia SDK by running this command: +**ステップ1:** [Kaia SDK](https://github.com/kaiachain/kaia-sdk)を使用してデプロイされたコントラクトと対話するには、以下のコマンドを実行してKaia SDKをインストールする必要があります： ```js npm install --save @kaiachain/ethers-ext ``` -**Step 2:** In the Explorer pane, Create a new folder called "utils" and click the New File button to create a new file named `kaia-sdk.js` in the utils folder. +**ステップ2:** エクスプローラーペインで、"utils "という新しいフォルダを作成し、"New File "ボタンをクリックして、utilsフォルダ内に`kaia-sdk.js`という新しいファイルを作成する。 -Step 3: Copy and paste the following code inside the file. +ステップ3：以下のコードをコピーしてファイル内に貼り付ける。 ```js const { JsonRpcProvider, Wallet } = require("@kaiachain/ethers-ext"); @@ -383,12 +383,12 @@ getTotalGreetings(contractAddress); // greet(contractAddress); ``` -**Step 4:** To execute any of the functions declared in this file, make sure to uncomment them as we did for the getTotalGreetings() function, then run the following command in your terminal. +**ステップ4：** このファイルで宣言されている関数を実行するには、getTotalGreetings()関数で行ったように、必ずコメントを解除してから、ターミナルで以下のコマンドを実行してください。 ```js -node utils/kaia-sdk.js +ノードユーティリティ/kaia-sdk.js ``` ![](/img/build/smart-contracts/pn-run-kaia-sdk.png) -For a more in-depth guide on hardhat-utils, please refer to [hardhat-utils github](https://github.com/ayo-klaytn/hardhat-utils). Also, you can find the full implementation of the code for this guide on [GitHub](https://github.com/ayo-klaytn/kaia-hardhat-utils-example) +hardhat-utilsのより詳細なガイドについては、[hardhat-utils github](https://github.com/ayo-klaytn/hardhat-utils)を参照してください。 また、このガイドのコードの完全な実装は、[GitHub](https://github.com/ayo-klaytn/kaia-hardhat-utils-example) にあります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md index cf02ccfe7fbc..45db5ea3313a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md @@ -1,78 +1,78 @@ -# Deploying smart contract using Thirdweb +# Thirdwebを使ったスマートコントラクトのデプロイ ![](/img/banners/kaia-thirdweb.png) -## Introduction +## はじめに -This section will guide you through deploying a Marketplace contract and a corresponding NFT collection contract to Klaytn Network using [ThirdWeb](https://portal.thirdweb.com/). Thirdweb is a complete web3 development framework that provides everything you need to connect your apps and games to decentralized networks. +このセクションでは、[ThirdWeb](https://portal.thirdweb.com/)を使用して、マーケットプレイス契約と対応するNFTコレクション契約をカイアネットワークにデプロイする方法を説明します。 Thirdwebは、あなたのアプリやゲームを分散型ネットワークに接続するために必要なすべてを提供する完全なWeb3開発フレームワークです。 -Marketplace contract allows users to list NFTs for direct sale or auction, thus enhancing the buying and selling of NFTs, just like it’s done on OpenSea. +マーケットプレイス契約により、ユーザーはNFTを直接販売やオークションに出品することができ、OpenSeaで行われているのと同様にNFTの売買を強化することができます。 -By the end of this guide, you will be able to: +このガイドの終わりには、あなたは次のことができるようになる： -- create and customize contracts using thirdweb. -- compile, deploy, and interact with your smart contract using thirdweb. +- サードウェブを使用して契約を作成し、カスタマイズします。 +- thirdwebを使用してスマートコントラクトをコンパイル、デプロイ、対話します。 -## Getting Started +## はじめに -In this article, we will explore the different means to create, customize, and deploy contracts using thirdweb, viz. +この記事では、サードウェブを使ってコントラクトを作成、カスタマイズ、デプロイするためのさまざまな手段を探ります。 -- Using the thirdweb dashboard -- Using the thirdweb CLI +- サードウェブダッシュボードの使用 +- thirdweb CLIを使う -For this guide, we will be demonstrating how to deploy a MarketPlace contract using the thirdweb dashboard and also deploying a corresponding nft collection to be listed on the marketplace using the thirdweb CLI. +このガイドでは、thirdwebダッシュボードを使用してMarketPlaceコントラクトをデプロイする方法と、thirdweb CLIを使用してマーケットプレイスに掲載される対応するnftコレクションをデプロイする方法を示します。 -> Note: We will not be explaining the mechanics of the marketplace contract as our focus is to explore thirdweb dashboard and CLI for creating, deploying, and interacting with smart contracts. +> 注：スマート・コントラクトの作成、デプロイ、相互作用のためのサードウェブ・ダッシュボードとCLIを探求することに重点を置くため、マーケットプレイス・コントラクトの仕組みについては説明しない。 -## Creating and deploying marketplace contract using thirdweb dashboard +## サードウェブダッシュボードを使用したマーケットプレイス契約の作成と展開 -In this section, we will create and deploy a marketplace contract using thirdweb dashboard. To do this, follow the steps below: +このセクションでは、thirdwebダッシュボードを使用してマーケットプレイス契約を作成し、デプロイします。 そのためには、以下の手順に従ってください： -1. Head over to [thirdweb dashboard](https://thirdweb.com/dashboard?ref=blog.thirdweb.com) and select the **MarketPlace** contract from the list of contracts. +1. [thirdweb dashboard](https://thirdweb.com/dashboard?ref=blog.thirdweb.com)にアクセスし、契約リストから**MarketPlace**契約を選択します。 ![](/img/build/get-started/marketplace-explore.png) -2. Click **Deploy Now** in the contract overview dashboard. +2. 契約概要ダッシュボードの**Deploy Now**をクリックします。 ![](/img/build/get-started/marketplace-deploy.png) -3. Configure the marketplace contract to include the following parameters: the **name** of the marketplace, its **description**, and **image**. +3. マーケットプレイスの**名**、**説明**、**画像**というパラメータを含むように、マーケットプレイスの契約を設定します。 ![](/img/build/get-started/marketplace-contract-details.png) -4. Click **Deploy Now** as seen in the image above and wait for the transaction to complete. +4. 上の画像のように**Deploy Now**をクリックし、トランザクションが完了するのを待ちます。 ![](/img/build/get-started/marketplace-deployed.png) -Once the transaction has been successfully executed, you can verify your deployment by pasting the contract address in the search bar of [Kaiascope](https://kaiascope.com/). +トランザクションが正常に実行されると、[Kaiascope](https://kaiascope.com/)の検索バーに契約アドレスを貼り付けることで、デプロイメントを確認することができます。 -## Creating and deploying an NFT collection contract using thirdweb CLI +## thirdweb CLIを使用したNFTコレクション契約の作成とデプロイ -In this section, we will create and deploy the NFT collection to be listed in our Marketplace using [thirdweb CLI](https://portal.thirdweb.com/cli?ref=blog.thirdweb.com). To do this, follow the steps below: +このセクションでは、[thirdweb CLI](https://portal.thirdweb.com/cli?ref=blog.thirdweb.com)を使用して、マーケットプレイスに掲載するNFTコレクションを作成し、デプロイします。 そのためには、以下の手順に従ってください： -### Creating the contract +### 契約書の作成 -1. Run this command in your terminal to create your contract: +1. ターミナルでこのコマンドを実行し、契約書を作成する： ```bash npx thirdweb create --contract ``` -2. Enter your preferred values for the command-line prompts: +2. コマンドラインのプロンプトにお好みの値を入力してください： - i. Give your project a name. + i. プロジェクトに名前をつける。 - ii. Choose your preferred framework: **Hardhat** or **Foundry**. + ii. お好きなフレームワークをお選びください：**Hardhat**または**Foundry**。 - iii. Name your smart contract. + iii. スマート・コントラクトに名前を付ける。 - iv. Choose the type of base contract: **Empty**, **ERC20**, **ERC721**, or **ERC1155**. Add any desired **extensions**. For this tutorial, we will select ERC721 and setting the extension to none. + iv. ベース契約のタイプを選択する：**Empty**、**ERC20**、**ERC721**、**ERC1155**。 必要な**拡張機能**を追加する。 このチュートリアルでは、ERC721を選択し、拡張子をnoneに設定します。 ![](/img/build/get-started/thirdweb-cli-info.png) -3. Once created, navigate to your project’s root directory and open your project in your preferred code editor. +3. 作成したら、プロジェクトのルート・ディレクトリに移動し、お好みのコード・エディタでプロジェクトを開いてください。 -4. If you open the contracts folder, your contract should look like this: +4. 契約書フォルダを開くと、契約書はこのようになっているはずだ： ```js // SPDX-License-Identifier: MIT @@ -97,73 +97,73 @@ contract nftcollection is ERC721Base { } ``` -The contract above demonstrates basic [ERC721Base](https://github.com/thirdweb-dev/contracts/blob/main/contracts/base/ERC721Base.sol) functionality. It imports and inherits the **ERC721Base** contract, and it also implements the required methods, including the constructor and its dependent parameters. +上記のコントラクトは、基本的な[ERC721Base](https://github.com/thirdweb-dev/contracts/blob/main/contracts/base/ERC721Base.sol)の機能を示している。 これは **ERC721Base** 契約をインポートして継承し、コンストラクタとその従属パラメータを含む必要なメソッドも実装している。 -You can modify the contract to your desired custom logic, and once done, your contract is ready for deployment. +コントラクトを希望のカスタム・ロジックに変更することができ、それが完了すれば、コントラクトをデプロイする準備が整う。 -### Deploying the contract +### 契約の展開 -1. Navigate to your project root folder and run the command in your terminal: +1. プロジェクトのルート・フォルダーに移動し、ターミナルでコマンドを実行する： ```bash npx thirdweb deploy ``` -Executing this command will trigger the following actions: +このコマンドを実行すると、以下のアクションがトリガーされる： -- detects the framework (hardhat, foundry) -- compiles all the contracts in the current directory. -- allows you to select which contract(s) you wish to deploy. -- upload your compiled smart contract code (in the form of an Application Binary Interface, or ABI) to IPFS. +- フレームワークを検出する（ハードハット、ファウンドリー） +- は、カレント・ディレクトリにあるすべてのコントラクトをコンパイルする。 +- をクリックすると、配備する契約を選択できます。 +- コンパイルしたスマートコントラクトのコードを（アプリケーション・バイナリ・インターフェース（ABI）の形で）IPFSにアップロードします。 -2. When deployment is complete, a dashboard interface will open to fill out the remaining parameters. - - **_name**: contract name - - **_symbol**: symbol or "ticker" - - **_royaltyRecipient**: wallet address to receive royalties from secondary sales - - **_royaltyBps**: basis points (bps) that will be given to the royalty recipient for each secondary sale, e.g., 500 = 5% +2. 配備が完了すると、ダッシュボードのインターフェイスが開き、残りのパラメータを入力する。 + - **_name**：契約名 + - **_symbol**：シンボルまたは "ティッカー" + - **__royaltyRecipient**：二次販売からのロイヤルティを受け取るウォレットアドレス + - **ロイヤリティBps**：二次販売ごとにロイヤリティ受取人に付与されるベーシス・ポイント（bps）。 -3. Select `Klaytn Mainnet Cypress` as the network to deploy the contract to. +3. 契約を展開するネットワークとして`Kaia Mainnet`を選択する。 ![](/img/build/get-started/nft-collection-deploy.png) -4. Once your smart contract is deployed, you can manage additional settings and functionalities through its dashboard. For example, you can upload NFTs, configure permissions and access control, and add new features. +4. スマート・コントラクトがデプロイされると、ダッシュボードから追加設定や機能を管理できる。 例えば、NFTのアップロード、権限やアクセス制御の設定、新機能の追加などが可能です。 -You can learn more about thirdweb deploy command in this [deploy guide](https://portal.thirdweb.com/deploy/getting-started). +thirdwebのデプロイコマンドについては、こちらの[デプロイガイド](https://portal.thirdweb.com/deploy/getting-started)を参照してください。 -## Interacting with deployed contracts +## 配備された契約とのやり取り -In this section, we will mint an NFT and also transferring it to another account using the **mint** and **transferfrom** function respectively. Let's go over it in the following steps: +このセクションでは、**mint**関数と**transferfrom**関数をそれぞれ使用して、NFTの造幣と別の口座への移管を行います。 次のステップで説明しよう： -### Minting the NFT +### NFTの鋳造 -1. Navigate to the newly deployed contract (**puppyKlan-NC**) dashboard. -2. Click on the **mint** function in the **NFTs** tab under the contract dashboard. +1. 新しく配置された契約 (**puppyKlan-NC**) のダッシュボードに移動して下さい。 +2. 契約ダッシュボードの**NFTs**タブにある**mint**機能をクリックします。 ![](/img/build/get-started/puppy-mint-btn.png) -3. Fill in the parameters needed for minting the NFT: **name**, **media**, **description**, and **properties**. +3. NFTの造幣に必要なパラメータを入力する：**name**、**media**、**description**、**properties**。 ![](/img/build/get-started/puppy-mint-details.png) -4. Verify your input and click the **Mint NFT** button. -5. Confirm the transaction and wait for it to complete. Once done, you should see your NFT added to the dashboard, like below: +4. 入力内容を確認し、**Mint NFT**ボタンをクリックします。 +5. 取引を確認し、完了するまで待つ。 完了すると、以下のようにダッシュボードにNFTが追加されます： ![](/img/build/get-started/puppy-minted.png) -### Transferring the NFT to a new owner +### 新オーナーへのNFT譲渡 -1. Head to the Explorer tab in the contract (**puppyKlan-NC**) dashboard. -2. Select the **transferFrom** function under the Write tab, as shown below. -3. Fill in the necessary function arguments: from (address), to (address), and id (uint256). +1. 契約(**puppyKlan-NC**)ダッシュボードのエクスプローラタブに向かう。 +2. 以下のように、Writeタブで**transferFrom**関数を選択する。 +3. 必要な関数の引数を記入する：from（アドレス）、to（アドレス）、id（uint256）。 ![](/img/build/get-started/puppy-transferfrom.png) -4. Confirm the transaction and wait for it to complete. +4. 取引を確認し、完了するまで待つ。 -## Conclusion +## 結論 -Congratulations! if you made it to the end of this guide. If you have any questions, visit the [Kaia Forum](https://devforum.kaia.io/) or reach out to the [official thirdweb support](https://support.thirdweb.com/). However, below is a list of useful resources you might need while further building with Thirdweb on Klaytn. +おめでとう！ このガイドを最後まで読んでくれたなら。 ご不明な点がございましたら、[カイアフォーラム](https://devforum.kaia.io/)、または[サードウェブ公式サポート](https://support.thirdweb.com/)までお問い合わせください。 しかし、以下は、Kaia上でThirdwebをさらに構築する際に必要となる可能性がある便利なリソースの一覧です。 -- [Thirdweb Docs](https://portal.thirdweb.com/) -- [How to build a dApp using Thirdweb](https://blog.thirdweb.com/guides/how-to-build-a-dapp/) -- [Create your own NFT marketplace with NextJS and TypeScript](https://blog.thirdweb.com/guides/nft-marketplace-with-typescript-next/) +- [サードウェブ・ドックス](https://portal.thirdweb.com/) +- [Thirdwebを使ったdAppの作り方](https://blog.thirdweb.com/guides/how-to-build-a-dapp/) +- [NextJSとTypeScriptで独自のNFTマーケットプレイスを作ろう](https://blog.thirdweb.com/guides/nft-marketplace-with-typescript-next/) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md index 29d7cd202ee4..d126f7f8bb6b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md @@ -1,23 +1,23 @@ -# IDE and Tools +# IDEとツール -This page contains the list of development tools that is available to help smart contract development on Klaytn. +このページには、Kaiaでのスマートコントラクト開発に役立つ開発ツールのリストが含まれています。 -#### [Remix Online IDE](https://remix.ethereum.org/) +#### [Remix Online IDE](https://remix.ethereum.org/) -Remix Online IDE is a powerful toolset for developing, deploying, debugging, and testing EVM-compatible smart contracts. You can write, compile, deploy and execute smart contracts on Klaytn from Remix IDE, using Klaytn Plugin. +Remix Online IDEは、EVM互換のスマートコントラクトを開発、デプロイ、デバッグ、テストするための強力なツールセットです。 Kaiaプラグインを使って、Remix IDEからKaia上でスマートコントラクトの記述、コンパイル、デプロイ、実行ができます。 -#### [Klaytn Contracts Wizard](https://wizard.klaytn.foundation/) +#### [Kaia Contracts Wizard](https://wizard.klaytn.foundation/) -Klaytn Contracts Wizard is an interactive generator to bootstrap your smart contract and learn about Klaytn Contracts. This is based on OpenZeppelin Wizard. +Kaiaコントラクトウィザードは、スマートコントラクトをブートストラップし、Kaiaコントラクトについて学ぶためのインタラクティブなジェネレーターです。 これはOpenZeppelin Wizardに基づいています。 #### [Thirdweb](../deploy/thirdweb.md) -Thirdweb is a complete web3 development framework that provides everything you need to connect your apps and games to decentralized networks. +Thirdwebは、あなたのアプリやゲームを分散型ネットワークに接続するために必要なすべてを提供する完全なWeb3開発フレームワークです。 -#### [Klaytn Wallet](../../tools/wallets/klaytn-wallet.md) +#### [Kaia Wallet](../../tools/wallets/kaia-wallet.md) -Kaia Wallet is a browser extension wallet for the Kaia Network. Kaia Wallet empowers you to store and interact with KAIA and your Kaia-based tokens. Kaia Wallet also enables you to sign transactions from web-based Kaia dApps in realtime. +カイアウォレットは、カイアネットワークのためのブラウザ拡張ウォレットです。 KAIAウォレットは、KAIAとKAIAベースのトークンを保管し、やり取りすることを可能にします。 カイア・ウォレットはまた、ウェブベースのカイアdAppsからのトランザクションにリアルタイムで署名することもできる。 -#### [Kaiascope](../../tools/block-explorers/kaiascope.md) +#### [カイアスコープ](../../tools/block-explorers/kaiascope.md) -Klaytnscope is the block explorer for the Klaytn Network. You can browse and inspect your transactions on the browser. +Kaiascopeはカイアネットワークのブロックエクスプローラーです。 ブラウザー上で取引を閲覧し、検査することができる。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md index 085247e2a956..bb64d5468b2b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md @@ -1,41 +1,41 @@ -# Import Ethereum Contracts +# イーサリアム契約のインポート -In most cases, you can use Ethereum contracts on Klaytn without any modification. -However, be aware of the following two issues. +ほとんどの場合、Ethereumの契約はKaia上で修正せずにそのまま使用できます。 +ただし、以下の2点には注意すること。 -## Solidity Support +## ソリディティ・サポート -- Cypress network is currently compatible with **London** Ethereum Virtual Machine (EVM). -- Baobab network is currently compatible with **London** Ethereum Virtual Machine (EVM). +- Kairosネットワークは現在、**ロンドン**イーサリアム仮想マシン（EVM）と互換性があります。 +- メインネットは現在、**ロンドン**イーサリアム仮想マシン（EVM）と互換性があります。 :::note -v1.7.0 Protocol Upgrade - incompatible changes including **Istanbul** hard fork items and Klaytn's own items. +v1.7.0プロトコルアップグレード - **Istanbul**ハードフォークアイテムとKaia自身のアイテムを含む互換性のない変更。 It has been enabled from block number `#75,373,312` in case of Baobab network and `#86,816,005` for the Cypress network. -v1.7.3 Protocol Upgrade - incompatible changes including Base Fee from the **London** hard fork. +v1.7.3プロトコルアップグレード - **ロンドン**ハードフォークからのベースフィーを含む互換性のない変更。 It has been enabled from block number `#80,295,291` in case of Baobab network and `#86,816,005` for the Cypress network. -v1.8.0 Protocol Upgrade - incompatible changes including Base Fee from the **London** hard fork. +v1.8.0プロトコルアップグレード - **ロンドン**ハードフォークからのベースフィーを含む互換性のない変更。 It has been enabled from block number `#86,513,895` in case of Baobab network and `#86,816,005` for the Cypress network. ::: -Backward compatibility is not guaranteed with other EVM versions on Klaytn. -Thus, it is highly recommended compiling Solidity code with the correct target option according to the protocol upgrade status. +Kaia上の他のEVMバージョンとの後方互換性は保証されていません。 +したがって、プロトコルのアップグレード状況に応じて、正しいターゲットオプションでSolidityコードをコンパイルすることを強くお勧めします。 -- Cypress: --evm-version london -- Baobab: --evm-version london -- Others(private/service chain): determined according to the protocol upgrade status +- Kairos: --evm-version london +- Mainnet: --evm-version london +- その他（プライベート／サービスチェーン）：プロトコルのアップグレード状況に応じて決定 -Please refer to [how to set the EVM version of solc](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#setting-the-evm-version-to-target). +[solcのEVMバージョンの設定方法](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#setting-the-evm-version-to-target)をご参照ください。 -An example command is shown below: +コマンドの例を以下に示す： ``` $ solc --evm-version london contract.sol ``` -## Decoupled Key Pairs +## 分離されたキー・ペア -Klaytn [decouples key pairs from addresses](../../learn/accounts.md#decoupling-key-pairs-from-addresses). If user [updates account](../../learn/transactions/basic.md#txtypeaccountupdate), the private key for a specific account is replaced with another one. Most cases this will not affect your business logic. However if your business logic includes ecrecover, you should consider using validateSender. For more details, refer to [here](../../learn/computation/precompiled-contracts.md). +カイア [キー・ペアをアドレスから切り離す](../../learn/accounts.md#decoupling-key-pairs-from-addresses)。 user [updates account](../../learn/transactions/basic.md#txtypeaccountupdate) とすると、特定のアカウントの秘密鍵が別のものに置き換えられる。 ほとんどの場合、ビジネスロジックには影響しません。 しかし、ビジネスロジックにecrecoverが含まれている場合は、validateSenderの使用を検討する必要があります。 詳細は[こちら](../../learn/computation/precompiled-contracts.md)を参照。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md index bb0f853fc09c..977e0b45424b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md @@ -1,10 +1,10 @@ # ERC-20 -## Introduction +## はじめに -This tutorial helps you to create an example ERC-20 compatible token that conforms to the [Klaytn Token Standards](../token-standard.md), especially [Fungible Token Standard (ERC-20)](../token-standard.md#fungible-token-standard-kip-7). +このチュートリアルでは、[Kaia Token Standards](../token-standard.md)、特に[Fungible Token Standard \(ERC-20)](../token-standard.md#fungible-token-standard-kip-7)に準拠した、ERC-20互換トークンの例を作成します。 -[ERC-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) defines two events and 9 methods (including 3 optional methods) as below. ERC-20-compatible tokens are token contracts that implements the following interface. +[ERC-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) defines two events and 9 methods (including 3 optional methods) as below. ERC-20互換トークンは、以下のインターフェイスを実装したトークンコントラクトです。 ```text function name() public view returns (string) //optional @@ -21,22 +21,22 @@ event Transfer(address indexed _from, address indexed _to, uint256 _value) event Approval(address indexed _owner, address indexed _spender, uint256 _value) ``` -Based on above interface, developers may customize tokens by adding new features and logics, and deploy on Klaytn network. For more information, refer to official [ERC-20 documentation](https://eips.ethereum.org/EIPS/eip-20). +上記のインターフェイスに基づき、開発者は新しい機能やロジックを追加することでトークンをカスタマイズし、Kaiaネットワークにデプロイすることができる。 詳細については、公式の[ERC-20ドキュメント](https://eips.ethereum.org/EIPS/eip-20)を参照してください。 -In this tutorial, you are going to implement `MyERC20.sol`, an ERC-20 compatible token. This token will issue a predefined amount of tokens and sends all of the tokens to the contract owner on its deploy. +このチュートリアルでは、ERC-20互換トークンである`MyERC20.sol`を実装する。 このトークンはあらかじめ定義された量のトークンを発行し、デプロイ時にすべてのトークンを契約オーナーに送信する。 -`MyERC20.sol` is based on OpenZeppelin's ERC20 implementation. A major part of the code in this tutorial is forked from [OpenZeppelin 2.3 ](https://github.com/OpenZeppelin/openzeppelin-solidity/releases/tag/v2.3.0) and following Solidity files are used to implement `MyERC20.sol`. +`MyERC20.sol`はOpenZeppelinのERC20実装に基づいている。 このチュートリアルのコードの大部分は[OpenZeppelin 2.3 ](https://github.com/OpenZeppelin/openzeppelin-solidity/releases/tag/v2.3.0)からフォークしたもので、`MyERC20.sol`を実装するために以下のSolidityファイルを使用しています。 - [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/IERC20.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/IERC20.sol) - [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20.sol) - [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Detailed.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Detailed.sol) - [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/math/SafeMath.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/math/SafeMath.sol) -## 1. Writing ERC-20 Smart Contract +## 1. ERC-20スマートコントラクトの作成 -### 1.1 Overall structure of MyERC20 +### 1.1 MyERC20の全体構造 -The complete source code of `MyERC20.sol` is given below. In this implementation, `constructor` invokes `_mint` to mint a predefined amount of token on contract deploy. +`MyERC20.sol`のソースコード全体を以下に示す。 この実装では、 `constructor` が `_mint` を呼び出して、コントラクトのデプロイ時にあらかじめ定義された量のトークンを鋳造する。 ```text pragma solidity ^0.5.0; @@ -426,20 +426,20 @@ contract MyERC20 is IERC20 { } ``` -`MyERC20.sol` consists of one interface `IERC20`, one library `SafeMath` and one contract `MyERC20` which implements `IERC20` interface. +`MyERC20.sol` は1つのインターフェース `IERC20`、1つのライブラリ `SafeMath`、そして `IERC20` インターフェースを実装した1つのコントラクト `MyERC20` から構成されている。 -- `IERC20` interface defines mandatory interface described at [ERC-20 specification](https://eips.ethereum.org/EIPS/eip-20). -- `SafeMath` library defines wrappers over Solidity's arithmetic operations with added overflow checks for safe calculation of `uint256` type of Solidity. -- `MyERC20` implements `IERC20` interfaces and also defines three optional methods described at [ERC-20 specification](https://eips.ethereum.org/EIPS/eip-20). - - In addition to ERC20, `constructor` is defined and this constructor is used to define a new ERC20 token name and symbol, and to mint a predefined amount of token. `constructor` is called once on its first deploy. +- IERC20\` インターフェースは、[ERC-20 仕様書](https://eips.ethereum.org/EIPS/eip-20) に記述されている必須インターフェースを定義する。 +- `SafeMath`ライブラリは、Solidityの `uint256` 型の安全な計算のためのオーバーフローチェックを追加した、Solidityの算術演算のラッパーを定義する。 +- MyERC20`は`IERC20\` インターフェースを実装し、[ERC-20 仕様書](https://eips.ethereum.org/EIPS/eip-20) で説明されている 3 つのオプションのメソッドも定義している。 + - ERC20に加えて、`コンストラクタ`が定義されており、このコンストラクタを使って新しいERC20トークンの名前とシンボルを定義し、あらかじめ定義された量のトークンを鋳造する。 コンストラクター\`は最初のデプロイ時に一度だけ呼ばれる。 -### 1.2 Take a look at important methods +### 1.2 重要なメソッドを見てみよう -Let's take a look at some important methods in detail. +いくつかの重要な方法を詳しく見てみよう。 #### (1) `function balanceOf(address account) external view returns (uint256);` -`balanceOf` is a mandatory method of ERC-20. `balanceOf` returns the balance of the given address. +`balanceOf`はERC-20の必須メソッドである。 `balanceOf` は指定されたアドレスの残高を返す。 ```text function balanceOf(address account) public view returns (uint256) { @@ -447,19 +447,19 @@ Let's take a look at some important methods in detail. } ``` -`balanceOf` just returns of value of key `account` stored in `_balances` which is `mapping (address => uint256)` type as below. +`balanceOf` は `_balances` に格納されているキー `account` の値を返すだけである。 ```text mapping (address => uint256) private _balances; ``` -If there is no key `account` available in `_balances`, then it just returns `0`. +もし `_balances` に `account` というキーがなければ、単に `0` を返す。 #### (2) `function transfer(address recipient, uint256 amount) external returns (bool);` -`transfer` is a mandatory method of ERC-20. `transfer` transfers `amount` of tokens to `recipient`, and MUST fire the `Transfer` event. The function SHOULD throw if the message caller’s account balance does not have enough tokens to spend. +転送`はERC-20の必須メソッドである。 また、 `Transfer\` イベントを発生させなければならない。 この関数は、メッセージ呼び出し元のアカウント残高が、使用するのに十分なトークンを 持っていない場合に throw すべきである(SHOULD)。 -`transfer` just invokes internal method `_transfer` which implements actual transfer and event as below. +`transfer`は内部メソッド `_transfer` を呼び出すだけで、以下のように実際の転送とイベントを実装している。 ```text function transfer(address recipient, uint256 amount) public returns (bool) { @@ -468,9 +468,9 @@ If there is no key `account` available in `_balances`, then it just returns `0`. } ``` -`_transfer` implements actual behavior of `transfer` method of ERC-20. +`_transfer` は ERC-20 の `transfer` メソッドの実際の動作を実装している。 -In addition, it prevents sending token from or to zero address using `require` as below. +また、以下のように `require` を使用することで、ゼロアドレスからのトークン送信やゼロアドレスへのトークン送信を防ぐことができます。 ```text function _transfer(address sender, address recipient, uint256 amount) internal { @@ -485,9 +485,9 @@ In addition, it prevents sending token from or to zero address using `require` a #### (3) `function approve(address spender, uint256 amount) external returns (bool);` -`approve` is a mandatory method of ERC-20. `approve` allows `spender` to withdraw from your account multiple times, up to the `amount`. If this function is called multiple times, it simply resets the allowance to `amount`. +`approve`はERC-20の必須メソッドである。 `approve`は `spender`が `amount`を上限として何度もあなたの口座から引き出すことを許可する。 この関数が複数回呼ばれた場合、単純に許容量を `amount` にリセットする。 -`approve` just invokes internal method `_approve` which implements actual behavior of `approve`. `msg.sender` is passed as the account `owner`. +これは `approve` の実際の動作を実装した内部メソッド `_approve` を呼び出すだけである。 `msg.sender`にはアカウント`owner`が渡される。 ```text function approve(address spender, uint256 value) public returns (bool) { @@ -504,15 +504,15 @@ In addition, it prevents sending token from or to zero address using `require` a } ``` -`_approve` updates `_allowances` which is a 2-dimensional dictionary maintaining allowed `value` for `spender` from specific `address`. +`_approve` は `_allowances` を更新する。この `_allowances` は、特定の `address` からの `spender` に対して許可される `value` を保持する 2 次元の辞書である。 ```text mapping (address => mapping (address => uint256)) private _allowances; ``` -#### (4) `function _mint(address account, uint256 amount) internal` +#### \(4\) `function _mint(address account, uint256 amount) internal` -`_mint` is not part of ERC-20. However we need a way to create new ERC-20 tokens and introduced `_mint` to create new tokens in this implementation as below. +`_mint`はERC-20の一部ではない。 しかし、新しいERC-20トークンを作成する方法が必要であり、この実装では以下のように新しいトークンを作成するために`_mint`を導入しました。 ```text function _mint(address account, uint256 amount) internal { @@ -524,58 +524,58 @@ In addition, it prevents sending token from or to zero address using `require` a } ``` -`_mint` is an internal method and can be invoked inside of this contract. +`_mint`は内部メソッドであり、このコントラクトの内部で呼び出すことができる。 -In `MyERC20.sol`, `_mint` is invoked only once from `constructor` when deploying the smart contract to mint a predefined amount of token. +`MyERC20.sol`では、`_mint`はスマートコントラクトをデプロイするときに`constructor`から一度だけ呼び出され、事前に定義された量のトークンを鋳造する。 -If you want to issue additional tokens after deploying the smart contract, you have to introduce a new public method such as `mint`. The method should be implemented with CAUTION because only authorized users should be able to mint tokens. +スマートコントラクトをデプロイした後で追加トークンを発行したい場合は、`mint`のような新しいパブリックメソッドを導入しなければならない。 トークンを鋳造できるのは許可されたユーザーだけであるべきなので、この方法は注意して実装されるべきである。 -Please take a look at OpenZeppelin example [ERC20Mintable.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Mintable.sol) for more detail. +詳しくはOpenZeppelinのサンプル[ERC20Mintable.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Mintable.sol)をご覧ください。 -## 2. Deploying Smart Contract +## 2. スマートコントラクトの導入 -In this section, you'll deploy your MyERC20 smart contract using Remix Online IDE. The complete source code for MYERC20.sol was given at [Writing ERC-20 Smart Contract](https://docs.kaia.io/build/smart-contracts/samples/erc-20/#1-writing-erc-20-smart-contract). +このセクションでは、Remix Online IDEを使ってMyERC20スマートコントラクトをデプロイします。 MYERC20.solの完全なソースコードは、[ERC-20スマートコントラクトの作成](https://docs.kaia.io/build/smart-contracts/samples/erc-20/#1-writing-erc-20-smart-contract)に記載されている。 -### 2.1 Prerequisites +### 2.1 前提条件 -- [Kaia Wallet](../../tools/wallets/kaia-wallet.md): used to deploy contracts, sign transactions and interact with contracts. -- Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. +- [Kaia Wallet](../../tools/wallets/kaia-wallet.md)：コントラクトのデプロイ、トランザクションへの署名、コントラクトとのやりとりに使用。 +- [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 -You can use Remix Online IDE or use Truffle to deploy `MyERC20` smart contract. +MyERC20\`スマートコントラクトをデプロイするには、Remix Online IDEを使用するか、Truffleを使用する。 -### 2.2 Deploying smart contract using Remix Online IDE +### 2.2 Remix Online IDEを使ったスマートコントラクトのデプロイ -Remix IDE +リミックスIDE -- Navigate to [Kaia Plugin for Remix](https://ide.kaia.io/) -- Create a `MyERC20.sol` file in the contracts folder -- In Remix, click **compile** contract. -- Click the Kaia (prev Klaytn) tab on your left having installed the plugin -- Select **Environment** > **Injected Provider** - **Kaia Wallet**. -- In Contract field, select your contract. For example, MyERC20. -- Assign the following arguments at deployment **KAIROSTOKEN**, **KAIROS** and **8** -- Click **Deploy**. +- [Kaia Plugin for Remix](https://ide.kaia.io/) に移動します。 +- contractsフォルダに`MyERC20.sol`ファイルを作成する。 +- Remixで**コンパイル**契約をクリックします。 +- プラグインをインストールしたら、左側のKaia (prev Klaytn) タブをクリックします。 +- **Environment** > **Injected Provider** - **Kaia Wallet** を選択します。 +- 契約フィールドで、契約を選択します。 例えば、MyERC20。 +- **KAIROSTOKEN**、**KAIROS**、_8_\* 配置で以下の引数を指定する。 +- 「Deploy」（展開）をクリックします。 ![ERC20-1-deploy](/img/build/smart-contracts/remix-layout-erc20-example.png) -After deploying, you can invoke `balanceOf` with your account, which was used to deploy the contract. You will find there are `10000000000000` tokens available in your account as below. Because you set `decimal` as `8` when deploying the contract above, it minted a fixed number of `100000` tokens in the constructor, with one token having a decimal value of `10^8`. `totalSupply` method will return the total supply of tokens minted which should be also `10000000000000`. +デプロイ後、コントラクトのデプロイに使用したアカウントで `balanceOf` を呼び出すことができる。 あなたのアカウントには以下のように`10000000000`トークンがあります。 上のコントラクトをデプロイするときに `decimal` を `8` に設定したため、コンストラクタで固定数の `100000` トークンが鋳造され、1 つのトークンは `10^8` の小数値を持つ。 `totalSupply`メソッドは、鋳造されたトークンの総供給量を返す。 ![ERC20-2-owner-token](/img/build/smart-contracts/bal-ts-erc20-example.png) -`MyERC20` is now live ! +MyERC20\`は現在ライブです！ -## 3. Interacting with ERC-20 token from Klaytn Wallet +## 3. Kaia WalletからERC-20トークンとやりとりする -You can use Kaia Wallet to check your balance and transfer the ERC-20-compatible KAIROSTOKEN you just deployed. To view your token balance in Kaia Wallet, follow the steps below: +カイアウォレットで残高を確認し、ERC-20互換のKAIROSTOKENを送金することができます。 カイアウォレットでトークン残高を確認するには、以下の手順に従ってください： -Kaia Wallet +カイア・ウォレット -- Open up Kaia Wallet -- Click on the Token List Icon, and then click Add Token button +- カイア・ウォレットを開く +- トークン一覧アイコンをクリックし、トークンの追加ボタンをクリックします。 ![](/img/build/smart-contracts/kaia-add-token-kw.png) -- Paste the address of myERC20.sol contract in the Token Contract Address field under Custom Token tab. -- Follow the prompts afterwards to add your token. Your Token List modal should like like this: +- カスタム・トークン]タブの[トークン契約アドレス]フィールドに、myERC20.sol 契約のアドレスを貼り付けます。 +- その後、指示に従ってトークンを追加してください。 トークンリスト・モーダルは次のようになります： ![](/img/build/smart-contracts/kaia-add-token-kw-ii.png) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md index b5a29bb9a786..8b91d10b738a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md @@ -1,11 +1,11 @@ # ERC-721 -## Introduction +## はじめに -This tutorial helps you to create an example ERC-721 compatible token that conforms to [Klaytn Token Standards](../token-standard.md), especially [Non-fungible Token Standard (ERC-721)](../token-standard.md#non-fungible-token-standard-kip-17). +このチュートリアルでは、[Kaia Token Standards](../token-standard.md)、特に[Non-fungible Token Standard (ERC-721)](../token-standard.md#non-fungible-token-standard-kip-17)に準拠したERC-721互換トークンの作成例を紹介します。 -[ERC-721 Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) defines three events and 10 methods as below. `supportsInterface` of ERC-721 is derived from [ERC-165 Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) and ERC-165 is a part of ERC-721. -ERC-721 compatible tokens are the token contracts that implement ERC-721 and ERC-165 interfaces as below. +[ERC-721 Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721)は、以下の3つのイベントと10のメソッドを定義している。 ERC-721の`supportsInterface`は[ERC-165 Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165)から派生したものであり、ERC-165はERC-721の一部である。 +ERC-721互換トークンとは、以下のようにERC-721とERC-165のインターフェースを実装したトークンコントラクトです。 ```solidity event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); @@ -24,20 +24,20 @@ function isApprovedForAll(address _owner, address _operator) external view retur function supportsInterface(bytes4 interfaceID) external view returns (bool); ``` -Based on above interface, developers may customize tokens by adding new features and logics, and deploy on Klaytn network. -For more information, refer to official [ERC-721 specification](https://eips.ethereum.org/EIPS/eip-721). +上記のインターフェイスに基づき、開発者は新しい機能やロジックを追加することでトークンをカスタマイズし、Kaiaネットワークにデプロイすることができる。 +詳しくは公式の[ERC-721仕様書](https://eips.ethereum.org/EIPS/eip-721)を参照。 -In this tutorial, you are going to implement `MyERC721Card.sol` which implements a card-type non-fungible token, i.e. `MyERC721Card`, which is an ERC-721 token. -Each `MyERC721Card` has name and level, e.g. "King" with level 1, "Queen" with level 1. +このチュートリアルでは、`MyERC721Card.sol`を実装する。このチュートリアルでは、`MyERC721Card`はERC-721トークンである。 +それぞれの`MyERC721Card`は名前とレベルを持っている。例えば、"King "はレベル1、"Queen "はレベル1である。 -`MyERC721Card.sol` is based on OpenZeppelin's ERC721 implementation. A major part of the code in this tutorial is forked from OpenZeppelin 2.3 +`MyERC721Card.sol`はOpenZeppelinのERC721実装に基づいている。 A major part of the code in this tutorial is forked from OpenZeppelin 2.3 . -## 1. Writing ERC-721 Smart Contract +## 1. ERC-721スマートコントラクトの作成 -### 1.1 Overall structure of MyERC721Card +### 1.1 MyERC721Cardの全体構造 -The complete source code of `MyERC721Card.sol` is given below. +`MyERC721Card.sol`の完全なソースコードを以下に示す。 ```text pragma solidity ^0.5.0; @@ -668,25 +668,25 @@ contract MyERC721Card is ERC721{ } ``` -`MyERC721Card.sol` consists of one interface(`IERC165`), three libraries(`Address`, `SafeMath` and `Counters`) and four contracts(`ERC165`, `IERC721`, `IERC721Receiver` and `MyERC721Card`). +`MyERC721Card.sol`は1つのインターフェース（`IERC165`）、3つのライブラリ（`Address`, `SafeMath` and `Counters`）、4つのコントラクト（`ERC165`, `IERC721`, `IERC721Receiver` and `MyERC721Card`）から構成される。 -- `IERC165` interface defines interface described at [ERC-165 specification](https://eips.ethereum.org/EIPS/eip-165). -- `Address` library defines `isContract` method to test whether an `account` is a contract or not. -- `SafeMath` library defines wrappers over Solidity's arithmetic operations with added overflow checks for safe calculation of `uint256` type of Solidity. -- `Counters` library defines counters that can only be incremented or decremented by one. This is used to track the number of elements in issuing ERC721 ids. -- `ERC165` implements `IERC165` interface. -- `IERC721` defines interface described at [ERC-721 specification](https://eips.ethereum.org/EIPS/eip-721) which also includes ERC-165. -- `IERC721Receiver` defines `onERC721Received` used from `MyERC721Card` contract. -- `ERC721` implements `IERC721` and `ERC165`. -- `MyERC721Card` implements a card type non-fungible token with name and level using `ERC721` and only the owner of `MyERC721Card` contract can mint new cards. +- IERC165\` インタフェースは、[ERC-165 仕様書](https://eips.ethereum.org/EIPS/eip-165) に記述されているインタフェースを定義する。 +- `Address`ライブラリは`isContract`メソッドを定義し、`account`が契約であるかどうかをテストする。 +- `SafeMath`ライブラリは、Solidityの `uint256` 型の安全な計算のためのオーバーフローチェックを追加した、Solidityの算術演算のラッパーを定義する。 +- `Counters`ライブラリは、1だけインクリメントまたはデクリメントできるカウンタを定義する。 これは、ERC721 IDを発行する際の要素数を追跡するために使用されます。 +- ERC165`は `IERC165\` インターフェースを実装している。 +- IERC721\`は[ERC-721仕様](https://eips.ethereum.org/EIPS/eip-721)に記述されているインターフェイスを定義しており、ERC-165も含まれている。 +- `IERC721Receiver` は `MyERC721Card` 契約から使用される `onERC721Received` を定義する。 +- ERC721`は `IERC721`と`ERC165\` を実装している。 +- `MyERC721Card`は、`ERC721`を使用して、名前とレベルを持つカード型の非可溶トークンを実装し、`MyERC721Card`の契約所有者のみが新しいカードを作成することができます。 -### 1.2 Take a look at important methods +### 1.2 重要なメソッドを見てみよう -Let's take a look at some important methods in detail. +いくつかの重要な方法を詳しく見てみよう。 #### (1) `constructor` of ERC721 and `_INTERFACE_ID_ERC721` -`constructor` registers `_INTERFACE_ID_ERC721` which is a 4 bytes hash derived from ERC-721 interfaces as below. +コンストラクタ `constructor` は `_INTERFACE_ID_ERC721` を登録する。`_INTERFACE_ID_ERC721` は ERC-721 インターフェースに由来する 4 バイトのハッシュで、以下のようになる。 ```text /* @@ -711,11 +711,11 @@ Let's take a look at some important methods in detail. } ``` -After registering, `supportsInterface` interface of ERC-721 and ERC-165 returns `true` when invoked for `_INTERFACE_ID_ERC721` and tells this contract is implementing ERC-721 interfaces. +登録後、ERC-721 と ERC-165 の `supportsInterface` インターフェースが `_INTERFACE_ID_ERC721` に対して呼び出されると `true` を返し、このコントラクトが ERC-721 インターフェースを実装していることを示す。 #### (2) `function balanceOf(address owner) public view returns (uint256 balance);` -`balanceOf` is a mandatory method of ERC-721. `balanceOf` returns the number of NFTs in `owner`'s account. +`balanceOf`はERC-721の必須メソッドである。 `balanceOf`は`owner`の口座にあるNFTの数を返す。 ```text function balanceOf(address owner) public view returns (uint256) { @@ -725,16 +725,16 @@ After registering, `supportsInterface` interface of ERC-721 and ERC-165 returns } ``` -`balanceOf` just returns a current count from the `Counter` object that the `owner` maintains in `_ownedTokensCount`. +`balanceOf` は `_owner` が `_TokensCount` に保持している `Counter` オブジェクトから現在のカウントを返すだけである。 ```text // Mapping from owner to number of owned token mapping (address => Counters.Counter) private _ownedTokensCount; ``` -#### (3) `safeTransferFrom` and `transferFrom` +#### \(3\) `safeTransferFrom` と `transferFrom` -These functions transfer the ownership of a given token ID to another address. There are two `safeTransferFrom` methods required by ERC-721, one with `data` and one without `data`. Both methods work identically to each other except that the one without `data` just set `data` to `""`. `safeTransferFrom` invokes `transferFrom` with more checks as below and `safeTransferFrom` is preferred over `transferFrom` which is also a mandatory method of ERC-721. +これらの関数は、指定されたトークンIDの所有権を別のアドレスに移す。 ERC-721が要求する `safeTransferFrom` メソッドは2つあり、1つは `data` 付きで、もう1つは `data` なしである。 どちらのメソッドも、`data` を使わない方は `data` に `""` をセットするだけであることを除けば、同じように動作する。 ERC-721の必須メソッドでもある`transferFrom`よりも`safeTransferFrom`の方が好ましい。 ```text function safeTransferFrom(address from, address to, uint256 tokenId) public { @@ -754,7 +754,7 @@ These functions transfer the ownership of a given token ID to another address. T } ``` -`safeTransferFrom` checks whether the `to` address is able to receive the token. `_checkOnERC721Received` has the verification logic. If `to` address is a contract, then the contract should implement `onERC721Received` interface of ERC-721 and return correct 4 bytes hash to receive ERC-721 token as below. +`safeTransferFrom` は `to` アドレスがトークンを受け取れるかどうかをチェックする。 `checkOnERC721Received`は検証ロジックを持つ。 もし `to` のアドレスがコントラクトの場合、コントラクトは ERC-721 の `onERC721Received` インターフェースを実装し、以下のように ERC-721 トークンを受信するための正しい 4 バイトのハッシュを返すべきである。 ```text function _checkOnERC721Received(address from, address to, uint256 tokenId, bytes memory _data) @@ -769,7 +769,7 @@ These functions transfer the ownership of a given token ID to another address. T } ``` -`_transferFrom` actually transfers ownership of a given `tokenId` as below. +実際に `_transferFrom` は指定された `tokenId` の所有権を以下のように転送する。 ```text function _transferFrom(address from, address to, uint256 tokenId) internal { @@ -789,7 +789,7 @@ These functions transfer the ownership of a given token ID to another address. T #### (4) `function _mint(address to, uint256 tokenId) internal` -`_mint` is not part of ERC-721. However we need a way to create new ERC-721 tokens and introduced `_mint` to create new tokens in this implementation as below. +`_mint`はERC-721の一部ではない。 しかし、我々は新しいERC-721トークンを作成する方法が必要であり、この実装では以下のように新しいトークンを作成するために`_mint`を導入しました。 ```text function _mint(address to, uint256 tokenId) internal { @@ -803,7 +803,7 @@ These functions transfer the ownership of a given token ID to another address. T } ``` -`_mint` is an internal method and can be invoked inside of this contract. In `MyERC721Card.sol`, `_mint` is invoked only from the `mintCard` method in the `MyERC721Card` contract. Only the owner of the smart contract can invoke `mintCard`. +`_mint`は内部メソッドであり、このコントラクトの内部で呼び出すことができる。 `MyERC721Card.sol` では、`_mint` は `MyERC721Card` コントラクトの `mintCard` メソッドからのみ呼び出される。 スマートコントラクトの所有者だけが `mintCard` を呼び出すことができる。 ```text function mintCard(string name, address account) public { @@ -814,30 +814,30 @@ These functions transfer the ownership of a given token ID to another address. T } ``` -## 2. Deploying Smart Contract +## 2. スマートコントラクトの導入 -You can use Remix Online IDE or use truffle to deploy above `MyERC721Card` smart contract. +RemixオンラインIDEまたはtruffleを使用して、上記の`MyERC721Card`スマートコントラクトをデプロイすることができます。 -### 2.1 Deploying smart contract using Remix Online IDE +### 2.1 Remix Online IDEを使ったスマートコントラクトのデプロイ -- Please visit [Kaia Plugin for Remix](https://ide.kaia.io) and create a `MyERC721Card` contract. The complete source code is given at [Writing ERC-721 Smart Contract](#1-writing-erc-721-smart-contract). -- Create an account to deploy the contract with. - - If you do not have an account yet, create one at [https://toolkit.kaia.io/account/accountKeyLegacy](https://toolkit.kaia.io/account/accountKeyLegacy). - - Get some test KAIA from the faucet - [https://faucet.kaia.io](https://faucet.kaia.io) -- Let's deploy `MyERC721Card.sol` as below. +- [Kaia Plugin for Remix](https://ide.kaia.io)にアクセスし、`MyERC721Card`契約を作成してください。 完全なソースコードは[ERC-721スマートコントラクトの作成](#1-writing-erc-721-smart-contract)にあります。 +- 契約を展開するためのアカウントを作成します。 + - まだアカウントをお持ちでない方は、[https://toolkit.kaia.io/account/accountKeyLegacy](https://toolkit.kaia.io/account/accountKeyLegacy)からアカウントを作成してください。 + - 蛇口からKAIAを試す - [https://faucet.kaia.io](https://faucet.kaia.io) +- 以下のように`MyERC721Card.sol`をデプロイしてみよう。 ![ERC721-1-deploy](/img/build/smart-contracts/erc721-1-deploy.png) -Now `MyERC721Card` is live! You can mint and transfer cards which are ERC-721 compatible non-fungible tokens. +これで`MyERC721Card`はライブになった！ ERC-721互換の非可溶性トークンであるカードを鋳造し、転送することができます。 -Let's mint two cards, i.e. `King` and `Queen` cards, for account `0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410` as below. +`0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410`の口座に`King`と`Queen`の2枚のカードを作成する。 ![ERC721-2-mint-king](/img/build/smart-contracts/erc721-2-mint-king.png) ![ERC721-3-mint-queen](/img/build/smart-contracts/erc721-3-mint-queen.png) -Now we have minted two cards and let's check the status of these `MyERC721Card` non-fungible token. +これで2枚のカードが鋳造されたので、`MyERC721Card`の非可菌トークンのステータスをチェックしてみよう。 ![ERC721-4-cards-status](/img/build/smart-contracts/erc721-4-cards-status.png) -- `balanceOf` shows that account `0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410` has two cards. -- `cards` with parameter `1` shows that `MyERC721Card` with token ID `1` is a `Queen` of level 1. -- `ownerOf` with parameter `0` shows that owner of `MyERC721Card` with token ID `0` is `0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410`. +- `balanceOf`はアカウント`0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410`が2枚のカードを持っていることを示している。 +- パラメータ `1` を持つ `cards` は、トークン ID `1` を持つ `MyERC721Card` がレベル 1 の `Queen` であることを示す。 +- パラメータ `0` を指定した `ownerOf` は、トークン ID `0` を持つ `MyERC721Card` の所有者が `0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410` であることを示しています。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md index 440864b999ab..b2297f601f08 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md @@ -1,8 +1,8 @@ # KaiaGreeter -`KaiaGreeter` is a simple contract that returns a greeting message. Greeting message is set when the contract is deployed. +`KaiaGreeter`は挨拶メッセージを返すシンプルなコントラクトである。 挨拶メッセージは契約展開時に設定されます。 -## Writing KaiaGreeter +## カイアグリーターの執筆 ``` pragma solidity 0.5.6; @@ -29,18 +29,18 @@ contract KaiaGreeter is Mortal { } ``` -## Deploying KaiaGreeter using Remix Online IDE +## RemixオンラインIDEを使ってKaiaGreeterをデプロイする -- Please visit [Kaia Plugin for Remix](https://ide.kaia.io) and create a `KaiaGreeter` contract. The complete source code was given in the above. -- Prepare your account which will be used to deploy the contract. - - If you do not have an account yet, create one at [https://toolkit.kaia.io/account/accountKeyLegacy](https://toolkit.kaia.io/account/accountKeyLegacy). - - Get some test KAIA from the faucet - [https://kairos.wallet.kaia.io/faucet](https://kairos.wallet.kaia.io/faucet) -- Deploy the contract with initial parameter, a greeting message. -- After deploying, you can invoke `greet` from the IDE. +- [Kaia Plugin for Remix](https://ide.kaia.io)にアクセスし、`KaiaGreeter`契約を作成してください。 完全なソースコードは上記の通り。 +- 契約を展開するために使用するアカウントを準備します。 + - まだアカウントをお持ちでない方は、[https://toolkit.kaia.io/account/accountKeyLegacy](https://toolkit.kaia.io/account/accountKeyLegacy)からアカウントを作成してください。 + - 蛇口からKAIAを試す - [https://kairos.wallet.kaia.io/faucet](https://kairos.wallet.kaia.io/faucet) +- 初期パラメータである挨拶メッセージを持つコントラクトをデプロイする。 +- デプロイ後、IDEから`greet`を呼び出すことができる。 -## References +## 参考文献 -For the details of contract deployment and the Remix Online IDE usage guideline, please refer to the following documents. +契約展開の詳細およびRemix Online IDE利用ガイドラインについては、以下のドキュメントをご参照ください。 - [Remix Online IDE](../../smart-contracts/ide-and-tools/ide-and-tools.md#kaia-ide) -- [Deploy Guide](../deploy/deploy.md) +- [デプロイガイド](../deploy/deploy.md) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md index 408958bc253d..63c2d1ddf7fe 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md @@ -1,4 +1,4 @@ -# Sample Contracts +# サンプル契約 ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md index 0b0c9b678050..1ce16332d344 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md @@ -1,10 +1,10 @@ -# Smart Contracts +# スマートコントラクト -This section covers the development resources for the Smart Contract development. +このセクションでは、スマートコントラクト開発のための開発リソースについて説明します。 -To write smart contracts, Klaytn currently supports [Solidity](https://github.com/ethereum/solidity) as the primary programming language. Solidity is adopted in Klaytn because it is a _de facto_ standard contract programming language for Ethereum and has a large user base and an active community. The Klaytn team decided to provide the users with familiar development experience so that the Ethereum DApp developers could easily experiment with or migrate their existing smart contracts to Klaytn. +スマートコントラクトを記述するために、カイアは現在、主要なプログラミング言語として[Solidity](https://github.com/ethereum/solidity)をサポートしている。 SolidityがKaiaで採用されているのは、それがイーサリアム用の事実上の標準コントラクト・プログラミング言語であり、大規模なユーザーベースと活発なコミュニティを持っているからだ。 Kaiaチームは、イーサリアムDAppの開発者が簡単に既存のスマートコントラクトを実験したり、Kaiaに移行したりできるように、使い慣れた開発経験をユーザーに提供することを決定した。 -In the future, Klaytn also plans to support writing smart contracts using other programming languages. The Klaytn team is investigating various favorable programming languages that developers might embrace. +将来的には、カイアは他のプログラミング言語を使ったスマートコントラクトの記述もサポートする予定だ。 カイア・チームは、開発者が受け入れやすいさまざまなプログラミング言語を調査している。 ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md index 9b3b4b8b377e..6dcddb6a31d9 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md @@ -1,47 +1,47 @@ -# Solidity - Smart Contract Language +# Solidity - スマートコントラクト言語 -This chapter describes only the high-level concepts, development processes, and examples written in Solidity because Solidity is already well documented on its official websites. For language specifications or implementations, please refer to the [References](#references) below. The content of this chapter is based on various websites listed in the [References](#references). +この章では、Solidity で記述された高レベルの概念、開発プロセス、例のみを説明します。 言語の仕様や実装については、以下の[参考文献](#references)をご参照ください。 本章の内容は、[参考文献](#references)に掲載されている様々なウェブサイトに基づいている。 -## Solidity and Klaytn +## SolidityとKaia -[Solidity](https://github.com/ethereum/solidity) is a high-level, statically typed, contract-oriented language for implementing smart contracts on the Ethereum platform. Although Solidity was originally designed for Ethereum, it is general enough to write smart contracts; therefore, it can also be used for other blockchain platforms, such as Klaytn. +[Solidity](https://github.com/ethereum/solidity) は、イーサリアムプラットフォーム上でスマートコントラクトを実装するための、高レベルの静的型付けされたコントラクト指向言語です。 Solidityはもともとイーサリアム用に設計されたものだが、スマートコントラクトを記述するのに十分な汎用性があるため、Kaiaなど他のブロックチェーンプラットフォームにも使用できる。 -Klaytn is officially compatible with **London** Ethereum Virtual Machine (EVM) version. Backward compatibility is not guaranteed with other EVM versions on Klaytn. Thus, it is highly recommended to compile Solidity code with the Istanbul target option. Please refer to [how to set the EVM version of solc](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#setting-the-evm-version-to-target). +Kaiaは、**ロンドン**のEthereum Virtual Machine (EVM) バージョンと正式に互換性があります。 カイアの他のEVMバージョンとの後方互換性は保証されません。 したがって、Istanbul ターゲットオプションを使用して Solidity コードをコンパイルすることを強く推奨します。 [solcのEVMバージョンの設定方法](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#setting-the-evm-version-to-target)をご参照ください。 :::note -v1.7.0 Protocol Upgrade - incompatible changes including **Istanbul** hard fork items and Klaytn's own items. +v1.7.0プロトコルアップグレード - **Istanbul**ハードフォークアイテムとKaia自身のアイテムを含む互換性のない変更。 It has been enabled from block number `#75,373,312` in case of Baobab network and `#86,816,005` for the Cypress network. -v1.7.3 Protocol Upgrade - incompatible changes including Base Fee from the **London** hard fork. +v1.7.3プロトコルアップグレード - **ロンドン**ハードフォークからのベースフィーを含む互換性のない変更。 It has been enabled from block number `#80,295,291` in case of Baobab network and `#86,816,005` for the Cypress network. -v1.8.0 Protocol Upgrade - incompatible changes including Base Fee from the **London** hard fork. +v1.8.0プロトコルアップグレード - **ロンドン**ハードフォークからのベースフィーを含む互換性のない変更。 It has been enabled from block number `#86,513,895` in case of Baobab network and `#86,816,005` for the Cypress network. ::: -Development tools such as [Remix](https://remix.ethereum.org/) (a browser-based IDE) and [Truffle](https://github.com/trufflesuite/truffle) (a development framework) can be utilized when developing smart contracts for Klaytn. The Klaytn team will attempt to maintain compatibility between Ethereum's development tools and Klaytn's but may elect to provide the Klaytn smart contract developers with enhanced or updated versions of those tools when necessary. +Kaiaのスマートコントラクトを開発する際には、[Remix](https://remix.ethereum.org/) ㊨や[Truffle](https://github.com/trufflesuite/truffle) ㊨などの開発ツールを利用することができます。 KaiaチームはEthereumの開発ツールとKaiaの開発ツール間の互換性を維持するよう努めますが、必要に応じてKaiaスマートコントラクト開発者にこれらのツールの拡張版または更新版を提供することを選択する可能性があります。 -It is convenient to utilize Remix or Truffle to develop smart contracts, but the Solidity compiler can be used locally, by building or installing it by following the instructions described in the web page below: +スマートコントラクトの開発には、RemixやTruffleを利用するのが便利ですが、Solidityコンパイラは、以下のウェブページに記載されている手順に従ってビルドまたはインストールすることで、ローカルで使用することができます： -- [Installing the Solidity Compiler](https://docs.soliditylang.org/en/latest/installing-solidity.html) +- [Solidityコンパイラのインストール](https://docs.soliditylang.org/en/latest/installing-solidity.html) -Note that there are two command-line Solidity compilers: +コマンドラインのSolidityコンパイラーは2つあります： -- _solc_: the full-featured compiler - - Covered in the Solidity documentation -- _solcjs_: Javascript binding for _solc_ - - Maintained as a separate project [solc-js](https://github.com/ethereum/solc-js) - - _solcjs_'s command-line options are not compatible with those of _solc_. +- _solc_: 高機能コンパイラ + - Solidity ドキュメント +- solcjs_：solc_のJavascriptバインディング + - 別プロジェクト[solc-js](https://github.com/ethereum/solc-js)として管理されている。 + - solcjs_のコマンドラインオプションは_solc_のものと互換性がない。 -Other materials that are useful for getting started with Solidity include the following: +その他、Solidity を使い始めるのに役立つ資料には次のようなものがあります： -- [Top Solidity tutorials](https://medium.com/coinmonks/top-solidity-tutorials-4e7adcacced8) +- [トップ・ソリディのチュートリアル](https://medium.com/coinmonks/top-solidity-tutorials-4e7adcacced8) -## How to Write a Smart Contract +## スマート・コントラクトの書き方 -This section presents an example of Solidity source code to provide readers with an idea of how smart contracts look and how to write a contract. Note that the code included here is provided solely for explanatory purposes; it is not intended for production purposes. In the code, `(require)` means that the line is required for any Solidity source file while `(optional)` indicates that the line is not always needed. The symbol `Ln:` is not part of the Solidity code and is included here only to show the line numbers. Please do not include these symbols in source code intended for real use. +このセクションでは、スマートコントラクトがどのように見え、どのようにコントラクトを書くかを読者に提供するために、Solidityソースコードの例を示します。 ここに含まれるコードは、説明のためだけに提供されるものであり、本番用ではないことに注意されたい。 コード中の(require)`は、その行がSolidityソースファイルに必要であることを意味し、(optional)`は、その行が必ずしも必要でないことを意味します。 記号 `Ln:` は Solidity のコードの一部ではないので、ここでは行番号を表示するためだけに含まれています。 これらの記号は、実際の使用を目的としたソースコードには含めないでください。 ```text L01: pragma solidity 0.5.12; // (required) version pragma @@ -66,72 +66,72 @@ L19: } L20: } ``` -The above code should be self-explanatory; thus people familiar with any other programming language can skip the following explanation in this section and jump to the next section. However, for those who do not gain a clear understanding of what the code does or those for whom Solidity is a first programming language, we include a short description of the source code below: +したがって、他のプログラミング言語に慣れている人は、このセクションの以下の説明を読み飛ばして、次のセクションに飛んでも構わない。 しかし、コードが何をするのか明確に理解できない人や、Solidityが初めてのプログラミング言語である人のために、以下にソースコードの簡単な説明を記載します： -- The portions of the code starting with a double forward slash (`//`) are comments rather than code; they are used to annotate and explain the code. The compiler ignores comments. -- The `pragma` statement in `L01` indicates the minimum compiler version. -- The `import` statement in `L03` imports all global symbols from "`filename`". The `filename` should be an actual file name. -- `L05` - `L20` define a smart contract called `UserStorage`. The keyword `contract` is located before the contract name and declares that the code represents a smart contract. Contracts in Solidity are similar to classes in object-oriented languages. Each contract can contain declarations for state variables, functions, function modifiers, events, struct types and enum types. Furthermore, contracts can inherit from other contracts. The example code contains one contract definition, but a single Solidity file may contain more than one contract definition. -- In `L07`, `userData` is a state variable for the mapping type. State variables are permanently stored in contract storage. The state variable `userData` maintains a mapping between `address` and a `uint` value. The `address` type holds a 20-byte address (Klaytn uses a 20-byte address similar to Ethereum). -- `L09` defines a public function `set` that saves the value `x` in `userData` for the message's sender. The variable `msg.sender` is a special variable defined in Solidity that represents the address of the message (_i.e._, current call) sender. The keyword `public` means that the function is part of the contract interface and can be called externally or internally. -- The functions `get` in `L13` and `getUserData` in `L17` are declared with `view`, which means that the functions promise not to modify any state variable. Their declarations include `returns (uint)`, which implies that they return a `uint` value. +- The portions of the code starting with a double forward slash (`//`) are comments rather than code; they are used to annotate and explain the code. コンパイラーはコメントを無視する。 +- `L01`の`pragma`文は、コンパイラの最小バージョンを示す。 +- `L03` の `import` ステートメントは、"`ファイル名`" からすべてのグローバルシンボルをインポートする。 `filename`は実際のファイル名でなければならない。 +- `L05` - `L20` は `UserStorage` というスマートコントラクトを定義している。 キーワード `contract` はコントラクト名の前にあり、コードがスマート・コントラクトを表すことを宣言する。 Solidity のコントラクトは、オブジェクト指向言語のクラスに似ています。 各コントラクトには、ステート変数、関数、関数修飾子、イベント、構造体タイプ、enumタイプの宣言を含めることができる。 さらに、契約は他の契約を継承することができる。 サンプルコードには 1 つのコントラクト定義が含まれていますが、1 つの Solidity ファイルには複数のコントラクト定義が含まれている場合があります。 +- `L07`では、`userData`はマッピングタイプの状態変数である。 状態変数はコントラクト・ストレージに恒久的に保存される。 状態変数 `userData` は `address` と `uint` 値の対応を保持する。 `address` 型は20バイトのアドレスを保持します（KaiaはEthereumと同様の20バイトのアドレスを使用します）。 +- `L09` では、メッセージの送信者の値 `x` を `userData` に保存するパブリック関数 `set` を定義しています。 変数 `msg.sender` は、Solidityで定義された特別な変数であり、メッセージ（つまり、現在のコール）の送信者のアドレスを表します。 `public`というキーワードは、その関数がコントラクト・インターフェースの一部であり、外部からも内部からも呼び出せることを意味する。 +- `L13` の `get` 関数と `L17` の `getUserData` 関数は `view` で宣言されている。 これらの宣言には `returns (uint)` が含まれており、これは `uint` 値を返すことを意味している。 -For more information concerning the syntax and semantics of the Solidity language, please refer to the [Solidity documentation](https://docs.soliditylang.org/). +Solidity 言語の構文とセマンティクスの詳細については、[Solidity ドキュメント](https://docs.soliditylang.org/) を参照してください。 -## How to Compile, Deploy, and Execute +## コンパイル、デプロイ、実行の方法 -One way to compile Solidity code is to use the command-line compiler _solc_. This compiler can produce various outputs, ranging from simple binaries and assembly to an abstract syntax tree (parse tree). Assuming that the code above is saved in `UserStorage.sol` (`L03` is excluded in the source file shown above), some examples of compiling the file `UserStorage.sol` are as follows. +Solidityコードをコンパイルする一つの方法は、コマンドラインコンパイラ_solc_を使用することです。 This compiler can produce various outputs, ranging from simple binaries and assembly to an abstract syntax tree (parse tree). 上記のコードを`UserStorage.sol`に保存すると仮定した場合（上記のソースファイルでは `L03` は除外されている）、`UserStorage.sol`をコンパイルする例を以下に示す。 ```bash $ solc --bin UserStorage.sol ``` -- This command will print the compilation output as a binary, _i.e._, bytecode. +- このコマンドはコンパイル出力をバイナリ、すなわちバイトコードとして表示する。 ```bash solc -o output --bin --ast --asm UserStorage.sol ``` -- The compiler generates a binary (by `--bin`), an abstract syntax tree (by `--ast`), and assembly code (by `--asm`) as separate files in the `output` directory. +- コンパイラは、バイナリの(`--bin`)ファイル、抽象構文木の(`--ast`)ファイル、アセンブ リコードの(`--asm`)ファイルを、それぞれ別のファイルとして `output` ディレクトリに生成します。 ```bash solc --optimize --bin UserStorage.sol ``` -- For better performance, the optimizer can be activated during compilation using the `--optimize` flag. +- より良いパフォーマンスを得るためには、コンパイル時に `--optimize` フラグを使ってオプティマイザを有効にすることができる。 -Some resources for compiling, deploying, and executing smart contracts are listed below. +スマート・コントラクトをコンパイル、デプロイ、実行するためのリソースを以下にいくつか挙げる。 -- [Using the Solidity command-line compiler](https://docs.soliditylang.org/en/latest/using-the-compiler.html) -- [Compiling contracts using Remix](https://remix-ide.readthedocs.io/en/stable/compile.html) -- [Running transactions with Remix](https://remix-ide.readthedocs.io/en/stable/run.html) -- [Remix Learneth Tutorials](https://remix-ide.readthedocs.io/en/latest/remix_tutorials_learneth.html) -- [Compiling contracts with Truffle](https://trufflesuite.com/docs/truffle/getting-started/compiling-contracts) -- [Deploying contracts with Truffle](https://trufflesuite.com/docs/truffle/getting-started/running-migrations) +- [Solidityコマンドラインコンパイラの使用](https://docs.soliditylang.org/en/latest/using-the-compiler.html) +- [Remixを使った契約のコンパイル](https://remix-ide.readthedocs.io/en/stable/compile.html) +- [リミックスによる取引の実行](https://remix-ide.readthedocs.io/en/stable/run.html) +- [リミックス・ラーネス・チュートリアル](https://remix-ide.readthedocs.io/en/latest/remix_tutorials_learneth.html) +- [Truffle による契約のコンパイル](https://trufflesuite.com/docs/truffle/getting-started/compiling-contracts) +- [Truffleでコントラクトを展開する](https://trufflesuite.com/docs/truffle/getting-started/running-migrations) -NOTE: This section will be updated in the future. +注：このセクションは将来更新される予定です。 -## Debugging Smart Contracts +## スマートコントラクトのデバッグ -It is more difficult to debug Solidity code than to debug code written in other programming languages due to the lack of mature debugging tools. Below, we list some resources for Solidity debugging. +Solidity のコードをデバッグするのは、他のプログラミング言語で書かれたコードをデバッグするよりも難しい。 以下に、Solidity のデバッグに関するリソースをいくつか示します。 -- [Debugging a transaction with Remix](https://remix-ide.readthedocs.io/en/latest/debugger.html) -- [Tutorial on debugging transactions with Remix](https://remix-ide.readthedocs.io/en/latest/tutorial_debug.html) -- [Debugging contracts with Truffle](https://trufflesuite.com/docs/truffle/getting-started/using-the-truffle-debugger/) +- [Remixによるトランザクションのデバッグ](https://remix-ide.readthedocs.io/en/latest/debugger.html) +- [Remixによるトランザクションのデバッグに関するチュートリアル](https://remix-ide.readthedocs.io/en/latest/tutorial_debug.html) +- [Truffleによる契約のデバッグ](https://trufflesuite.com/docs/truffle/getting-started/using-the-truffle-debugger/) -NOTE: This section will be updated in the future. +注：このセクションは将来更新される予定です。 -## Smart Contract Best Practices +## スマート・コントラクトのベスト・プラクティス -To eliminate security concerns and code quality issues from your smart contract, it is important to study and follow best practices in Solidity programming. Here, we show a reference for Solidity best practices. +スマートコントラクトからセキュリティの懸念とコード品質の問題を取り除くには、Solidityプログラミングのベストプラクティスを学び、それに従うことが重要です。 ここでは、Solidityのベストプラクティスのリファレンスを示します。 -- [Smart Contract Security Best Practices](https://github.com/ConsenSys/smart-contract-best-practices) +- [スマート・コントラクト・セキュリティのベスト・プラクティス](https://github.com/ConsenSys/smart-contract-best-practices) -NOTE: This section will be updated in the future. +注：このセクションは将来更新される予定です。 -## References +## 参考文献 -- [Solidity GitHub page](https://github.com/ethereum/solidity) -- [Solidity documentation](https://solidity.readthedocs.io/en/latest/index.html) -- [Remix documentation](https://remix-ide.readthedocs.io/en/latest/) -- [Truffle documentation](https://trufflesuite.com/docs/truffle/) +- [Solidity GitHubページ](https://github.com/ethereum/solidity) +- [Solidity ドキュメント](https://solidity.readthedocs.io/en/latest/index.html) +- [リミックス・ドキュメント](https://remix-ide.readthedocs.io/en/latest/) +- [トリュフ・ドキュメント](https://trufflesuite.com/docs/truffle/) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md index 179fc308eefd..9e0ffd8e4073 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md @@ -1,21 +1,21 @@ -# Test Smart Contracts +# スマートコントラクトのテスト -In this section, we'll introduce how to test smart contracts. Because any transaction on the blockchain is not reversible, testing your smart contract is crucial before you deploy the contract. +このセクションでは、スマート・コントラクトのテスト方法を紹介する。 ブロックチェーン上の取引は元に戻せないため、スマート・コントラクトをデプロイする前にテストすることが重要だ。 -## Testing with Truffle +## トリュフを使ったテスト -Truffle provides an automated testing framework. This framework lets you write simple and manageable tests in two different ways: +Truffleは自動テストのフレームワークを提供する。 このフレームワークを使うと、シンプルで管理しやすいテストを2種類の方法で書くことができる： -- In `Javascript` and `TypeScript`, for exercising your contracts from the outside world, just like application. -- In `Solidity`, for exercising your contracts in advances, bare-to-the-metal scenarios. +- `Javascript`と`TypeScript`では、アプリケーションと同じように、外界から契約を行使することができる。 +- `Solidity`では、前進、ベアトゥザメタル・シナリオで契約を行使する。 ### Getting started -We will follow the [Deployment Guide using Truffle](./deploy/deploy.md#truffle) to create a contract and deploy it. But, before we deploy it, we will add a setter function `setGreet` to the contract for testing purpose. The source code is given below. +ここでは、[Truffleを使用したデプロイメント・ガイド](./deploy/deploy.md#truffle)に従ってコントラクトを作成し、デプロイします。 しかし、デプロイする前に、テストのためにコントラクトにセッター関数 `setGreet` を追加する。 ソースコードを以下に示す。 -**NOTE:** We have made some modifications to the contract for testing. +\*\*注：\*\*テストのため、契約を一部変更しました。 -Below is KlaytnGreeting contract source code. +以下は、KaiaGreetingの契約ソースコードです。 ``` pragma solidity 0.5.6; @@ -29,7 +29,7 @@ contract Mortal { function kill() public payable { if (msg.sender == owner) selfdestruct(owner); } } -contract KlaytnGreeter is Mortal { +contract KaiaGreeter is Mortal { /* Define variable greeting of the type string */ string greeting; @@ -52,9 +52,9 @@ contract KlaytnGreeter is Mortal { } ``` -We will test 1) `greet()` function whether it returns "Hello, Klaytn" message properly, 2) `setGreet()` function whether it set new greeting message properly and reverts when non-owner account attempts to update the greeting. +1\)`greet()`関数が "Hello, Kaia "メッセージを正しく返すかどうか、2)`setGreet()`関数が新しい挨拶メッセージを正しく設定し、所有者でないアカウントが挨拶を更新しようとすると元に戻るかどうかをテストする。 -First, we will install the Chai assertions library (or any different assertions library you use) for generic assertions, and the truffle-assertions library for the smart contract assertions. +最初に、一般的なアサーションのためにChaiアサーション・ライブラリ（またはあなたが使用する別のアサーション・ライブラリ）をインストールし、スマート・コントラクトのアサーションのためにtruffle-assertionsライブラリをインストールします。 ``` npm install --save-dev chai truffle-assertions @@ -62,9 +62,9 @@ npm install --save-dev chai truffle-assertions ### Writing test in Solidity -Testing with Solidity can be a little bit more intuitive than JavaScript tests. Solidity test contracts live alongside JavaScript tests as .sol files. +Solidity を使用したテストは、JavaScript を使用したテストよりも少し直感的です。 Solidity テスト契約は、JavaScript テストと一緒に .sol ファイルとして保存されます。 -Create a file called `TestKlaytnGreeting.sol` in the `test` folder. The Truffle suite provides us with helper libraries for testing, so we need to import those. Let's take a look at the example Solidity test: +`test`フォルダに`TestKaiaGreeting.sol`というファイルを作成する。 Truffleスイートはテスト用のヘルパー・ライブラリを提供しているので、それらをインポートする必要がある。 Solidityテストの例を見てみよう： ``` pragma solidity ^0.5.6; @@ -74,25 +74,25 @@ import "truffle/DeployedAddresses.sol"; import "../contracts/HashMarket.sol"; ``` -- Assert : It gives us access to various testing functions, like `Assert.equals()`, `Assert.greaterThan()`, etc. -- DeployedAddresses : Every time you change your contract, you must redeploy it to a new address. You can get the deployed contract addresses through this library. +- Assert ：Assert.equals()`や`Assert.greaterThan()\`など、様々なテスト関数にアクセスできる。 +- DeployedAddresses : 契約を変更するたびに、新しいアドレスに再デプロイする必要があります。 このライブラリを通じて、デプロイされた契約アドレスを取得することができる。 -Now, Let's write a test code. +では、テストコードを書いてみよう。 ``` pragma solidity ^0.5.6; import "truffle/Assert.sol"; import "truffle/DeployedAddresses.sol"; -import "../contracts/KlaytnGreeter.sol"; +import "../contracts/KaiaGreeter.sol"; -contract TestKlaytnGreeter { +contract TestKaiaGreeter { function testGreetingMessage() public { - // DeployedAddresses.KlaytnGreeter() handles contract address. - KlaytnGreeter greeter = KlaytnGreeter(DeployedAddresses.KlaytnGreeter()); + // DeployedAddresses.KaiaGreeter() handles contract address. + KaiaGreeter greeter = KaiaGreeter(DeployedAddresses.KaiaGreeter()); - string memory expectedGreet = "Hello Klaytn"; + string memory expectedGreet = "Hello Kaia"; string memory greet = greeter.greet(); @@ -101,7 +101,7 @@ contract TestKlaytnGreeter { } ``` -Run your Solidity test code. +Solidity テストコードを実行します。 ``` $ truffle test @@ -111,11 +111,11 @@ Using network 'development'. Compiling your contracts... =========================== -> Compiling ./test/TestKlaytnGreeter.sol +> Compiling ./test/TestKaiaGreeter.sol - TestKlaytnGreeter + TestKaiaGreeter 1) testGreetingMessage Events emitted during test: @@ -128,17 +128,17 @@ Compiling your contracts... 0 passing (5s) 1 failing - 1) TestKlaytnGreeter + 1) TestKaiaGreeter testGreetingMessage: - Error: greeting message should match (Tested: Hello, Klaytn, Against: Hello Klaytn) + Error: greeting message should match (Tested: Hello, Kaia, Against: Hello Kaia) at result.logs.forEach.log (/Users/jieunkim/.nvm/versions/node/v10.16.0/lib/node_modules/truffle/build/webpack:/packages/core/lib/testing/soliditytest.js:71:1) at Array.forEach () at processResult (/Users/jieunkim/.nvm/versions/node/v10.16.0/lib/node_modules/truffle/build/webpack:/packages/core/lib/testing/soliditytest.js:69:1) at process._tickCallback (internal/process/next_tick.js:68:7) ``` -Oops, we failed. Let's check the error message,`Error: greeting message should match (Tested: Hello, Klaytn, Against: Hello Klaytn)`. I can notice the missed `',(comma)'` at _string memory expectedGreet = "Hello Klaytn"_.\ -Fix the code and run the test again. +おっと、失敗した。 エラーメッセージ`Error: greeting message should match (Tested: Hello, Kaia, Againstst: Hello Kaia)`を確認してみよう。 文字列メモリ expectedGreet = "Hello Kaia"_.∕ +コードを修正して、もう一度テストを実行してください。 ``` $ truffle test @@ -148,43 +148,43 @@ Using network 'development'. Compiling your contracts... =========================== -> Compiling ./test/TestKlaytnGreeter.sol +> Compiling ./test/TestKaiaGreeter.sol - TestKlaytnGreeter + TestKaiaGreeter ✓ testGreetingMessage (58ms) 1 passing (5s) ``` -Congratulations! Your test has passed. +おめでとう！ テストは合格だ。 ### Writing test in JavaScript -Truffle uses the [Mocha](https://mochajs.org/) testing framework and [Chai](https://www.chaijs.com/) assertion library to provide a solid framework for JavaScript test. JavaScript test gives you more flexibility and enables you to write more complex tests. +Truffle は、[Mocha](https://mochajs.org/) テストフレームワークと [Chai](https://www.chaijs.com/) アサーションライブラリを使用し、JavaScript テストのための強固なフレームワークを提供します。 JavaScriptテストは、より柔軟性があり、より複雑なテストを書くことができる。 -Let's create a file and name it `0_KlaytnGreeting.js` under `test` directory.\\ +それでは、`test`ディレクトリの下に`0_KaiaGreeting.js`という名前のファイルを作ってみよう。 -The test code is: +テストコードはこうだ： ```javascript -// Interacting directly with KlaytnGreeter contract -const KlaytnGreeter = artifacts.require("./KlaytnGreeter.sol"); +// Interacting directly with KaiaGreeter contract +const KaiaGreeter = artifacts.require("./KaiaGreeter.sol"); const truffleAssert = require('truffle-assertions'); -contract("KlaytnGreeter", async(accounts) => { +contract("KaiaGreeter", async(accounts) => { // store the contract instance at a higher level // to enable access from all functions. var klaytnGreeterInstance; var owner = accounts[0]; - var greetMsg = "Hello, Klaytn"; + var greetMsg = "Hello, Kaia"; // This will run before each test proceed. before(async function() { // set contract instance into a variable - klaytnGreeterInstance = await KlaytnGreeter.new(greetMsg, {from:owner}); + klaytnGreeterInstance = await KaiaGreeter.new(greetMsg, {from:owner}); }) it("#1 check Greeting message", async function() { @@ -196,7 +196,7 @@ contract("KlaytnGreeter", async(accounts) => { }) it("#2 update greeting message.", async function() { - var newGreeting = "Hi, Klaytn"; + var newGreeting = "Hi, Kaia"; await klaytnGreeterInstance.setGreet(newGreeting, { from:owner }); var greet = await klaytnGreeterInstance.greet(); @@ -210,24 +210,24 @@ contract("KlaytnGreeter", async(accounts) => { }); ``` -If you are unfamiliar with `Mocha` unit test, please check the [Mocha document](https://mochajs.org/#getting-started). +もし `Mocha` ユニットテストに馴染みがなければ、[Mocha ドキュメント](https://mochajs.org/#getting-started) を参照してください。 -- Use `contract()` instead of `describe()` +- describe()`の代わりに `contract()\` を使う。 - Structurally, the Truffle test code shouldn't be much different from the usual test code of Mocha. Your test should contain the code that Mocha will recognize it as an automated test. The difference between Mocha and Truffle test is the contract() function. + 構造的には、Truffleのテストコードは通常のMochaのテストコードとあまり変わらないはずです。 テストには、Mocha が自動テストとして認識するコードを含める必要があります。 MochaとTruffleのテストの違いは、contract()関数です。 - **NOTE** the use of the `contract()` function, and the `accounts` array for specifying available Klaytn accounts. -- Contract abstractions within your tests + **注**：`contract()` 関数と、利用可能な Kaia アカウントを指定するための `accounts` 配列の使用に注意してください。 +- テスト内で抽象化を契約する - Since Truffle has no way of detecting which contract you'll need to interact with during test, you should specify the contract explicitly. One way to do this is by using the `artifacts.require()` method. -- `it` syntax + Truffle には、テスト中にどのコントラクトとやり取りする必要があるかを検出する手段がないため、コントラクトを明示的に指定する必要があります。 これを行う一つの方法は、`artifacts.require()`メソッドを使うことである。 +- `it`構文 - This represents each test case with description. The description will print on the console on test-run. -- `truffle-assertion` library + これは各テストケースを説明とともに表している。 説明文はテスト実行時にコンソールに表示される。 +- `truffle-assertion`ライブラリ - This library allows you to easily test reverts or other failures by offering the `truffleAssert.reverts()` and `truffleAssert.fails()` functions. + このライブラリは `truffleAssert.reverts()` と `truffleAssert.fails()` 関数を提供し、差し戻しやその他の失敗を簡単にテストできるようにします。 -The output should like the following: +出力は以下のようになるはずだ： ``` Using network 'development'. @@ -239,7 +239,7 @@ Compiling your contracts... - Contract: KlaytnGreeter + Contract: KaiaGreeter ✓ #1 check Greeting message ✓ #2 update greeting message. (46ms) ✓ #3 [Failure test] Only owner can change greeting. @@ -248,14 +248,14 @@ Compiling your contracts... 3 passing (158ms) ``` -Congratulations! Your test has passed. +おめでとう！ テストは合格だ。 ### Specifying test -You can choose the test file to be executed. +実行するテストファイルを選択できる。 ``` -truffle test ./test/0_KlaytnGreeting.js +truffle test ./test/0_KaiaGreeting.js ``` -For more details, please check [Truffle testing](https://www.trufflesuite.com/docs/truffle/testing/testing-your-contracts) and [Truffle commands](https://www.trufflesuite.com/docs/truffle/reference/truffle-commands#test) for details. +詳しくは、[Truffle testing](https://www.trufflesuite.com/docs/truffle/testing/testing-your-contracts)、[Truffle commands](https://www.trufflesuite.com/docs/truffle/reference/truffle-commands#test)をご覧ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md index aed54ad15d75..7b6300790778 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md @@ -1,16 +1,16 @@ -# Klaytn Compatible Tokens (KCTs) +# Kaia Compatible Tokens (KCTs) -Klaytn Compatible Token (KCT) is a special type of smart contract that implements certain technical specifications. Everyone who wants to issue tokens on top of Klaytn must follow the specification. +Kaia Compatible Tokens（KCT）は、特定の技術仕様を実装した特別なタイプのスマートコントラクトである。 カイアの上でトークンを発行したい人は皆、この仕様に従わなければならない。 -Token standards are defined in Kaia such as [KIP-7](https://kips.kaia.io/KIPs/kip-7) and [KIP-17](https://kips.kaia.io/KIPs/kip-17). +Kaiaでは、[KIP-7](https://kips.kaia.io/KIPs/kip-7)や[KIP-17](https://kips.kaia.io/KIPs/kip-17)といったトークンの規格が定義されている。 -Other KCTs can be defined to meet certain technical specifications. If anyone needs other token standards, please visit [Kaia Improvement Proposal](https://github.com/kaiachain/KIPs) and propose a new token standard. +その他のKCTは、特定の技術仕様を満たすように定義することができる。 他のトークン規格が必要な方は、[カイア改善提案](https://github.com/kaiachain/KIPs)にアクセスして、新しいトークン規格を提案してください。 ## Fungible Token Standard (KIP-7) -Fungible tokens are tokens that have properties of uniformity and divisibility. Every fungible token is interchangeable as each unit of token possesses the same value. Just like every dollar bill has the same value of one dollar. Since fungibility is essential feature to crypto currency in most cases, large proportion of blockchain tokens are fungible tokens. +菌類トークンとは、均一性と可分性の特性を持つトークンのことである。 各トークンは同じ価値を持つため、すべてのカンジブル・トークンは交換可能である。 すべてのドル紙幣が同じ1ドルの価値を持つように。 ほとんどの場合、暗号通貨には両替性が不可欠であるため、ブロックチェーントークンの大部分は両替可能なトークンである。 -To implement these properties with smart contracts, KIP-7 token standard can be used. KIP-7-compatible tokens implement the following interface. Please note that [KIP-13](https://kips.kaia.io/KIPs/kip-13) must be implemented together. For wallet applications, [wallet interface](https://kips.kaia.io/KIPs/kip-7#wallet-interface) can be implemented. +これらの特性をスマート・コントラクトで実装するために、KIP-7トークン標準を使用することができる。 KIP-7 互換トークンは以下のインタフェースを実装する。 なお、[KIP-13](https://kips.kaia.io/KIPs/kip-13)は必ず一緒に実装すること。 ウォレットアプリケーションのために、[ウォレットインターフェース](https://kips.kaia.io/KIPs/kip-7#wallet-interface)を実装することができる。 ```solidity // IKIP7 @@ -55,19 +55,19 @@ function addPauser(address _account) external; function renouncePauser() external; ``` -Based on the interface above, developers may customize tokens by adding new features and logics, and deploy them on Klaytn network. +上記のインターフェイスに基づき、開発者は新しい機能やロジックを追加することでトークンをカスタマイズし、Kaiaネットワークにデプロイすることができる。 -For more information, refer to the official [KIP-7 documentation](https://kips.kaia.io/KIPs/kip-7). +詳細については、公式の[KIP-7ドキュメント](https://kips.kaia.io/KIPs/kip-7)を参照してください。 -- An example implementation is available at [https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP7/KIP7.sol](https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP7/KIP7.sol). +- 実装例は[https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP7/KIP7.sol](https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP7/KIP7.sol)にある。 ## Non-fungible Token Standard (KIP-17) -Non-fungible token (NFT) is a special type of token that represents a unique asset. As the name non-fungible implies, every single token is unique and non-divisible. This uniqueness of non-fungible token opens up new horizons of asset digitization. For example, it can be used to represent digital art, game items, or any kind of unique assets and allow people to trade them. +Non-fungible token (NFT) is a special type of token that represents a unique asset. Non-fungibleという名前が示すように、すべてのトークンは一意であり、分割不可能である。 この非可菌トークンの独自性は、資産のデジタル化に新たな地平を開く。 例えば、デジタルアート、ゲームアイテム、あるいはあらゆる種類のユニークな資産を表現し、人々がそれらを取引できるようにするために使用することができる。 -For example, a blockchain collection game [Cryptokitties](https://www.cryptokitties.co/) implements non-fungible token to represent different kitties that have different genetic information. Every kitty is unique and non-interchangeable, resulting in different values for different kitty tokens. +例えば、ブロックチェーン・コレクション・ゲーム[Cryptokitties](https://www.cryptokitties.co/)は、異なる遺伝情報を持つ異なる子猫を表現するために、非可菌トークンを実装している。 すべてのキティは一意であり、交換不可能であるため、キティ・トークンによって価値が異なる。 -To implement non-fungible token, [KIP-17](https://kips.kaia.io/KIPs/kip-17) can be used. KIP-17 token contracts implement the following interface. Please note that [KIP-13](https://kips.kaia.io/KIPs/kip-13) must be implemented together. For wallet applications, [wallet interface](https://kips.kaia.io/KIPs/kip-17#wallet-interface) can be implemented. +非可溶性トークンを実装するには、[KIP-17](https://kips.kaia.io/KIPs/kip-17)を使用することができます。 KIP-17トークンコントラクトは以下のインタフェースを実装する。 なお、[KIP-13](https://kips.kaia.io/KIPs/kip-13)は必ず一緒に実装すること。 ウォレットアプリケーションのために、[ウォレットインターフェース](https://kips.kaia.io/KIPs/kip-17#wallet-interface)を実装することができる。 ```solidity // IKIP17 @@ -121,18 +121,18 @@ function addPauser(address _account) public; function renouncePauser() public; ``` -Based on the interface above, developers may customize tokens by adding new features and logics, and deploy them on Klaytn network. +上記のインターフェイスに基づき、開発者は新しい機能やロジックを追加することでトークンをカスタマイズし、Kaiaネットワークにデプロイすることができる。 -For more information, refer to the official [KIP-17 documentation](https://kips.kaia.io/KIPs/kip-17). +詳しくは、公式の[KIP-17ドキュメント](https://kips.kaia.io/KIPs/kip-17)を参照してください。 -- An example implementation is available at [https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP17/KIP17.sol](https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP17/KIP17.sol). +- 実装例は[https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP17/KIP17.sol](https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP17/KIP17.sol)にある。 -## Token Standards for Klaytn Service Chain +## カイア・サービス・チェーンのトークン標準 -Service chain refers to Klaytn's side chain that anchors to Klaytn's main blockchain network. When implementing a service chain, special type of contracts are used to support value transfer between the main chain and the service chain. These contracts are currently under development, and when they are ready, the token specifications for Klaytn service chain will be provided on KlaytnDocs. +サービスチェーンとは、カイアのメインブロックチェーンネットワークに固定されたカイアのサイドチェーンを指す。 サービス・チェーンを実施する場合、メイン・チェーンとサービス・チェーン間の価値移転をサポートするために、特別なタイプの契約が使用される。 これらの契約は現在開発中であり、準備が整い次第、Kaiaサービスチェーン用のトークン仕様をKaiaDocsで提供する。 -## Notes on ERC-20 and ERC-721 +## ERC-20およびERC-721に関する注意事項 -Since Klaytn published KIP-7 and KIP-17 as its token standards, it is recommended to implement fungible and non-fungible token contracts according to KIP-7 and KIP-17, respectively, rather than following ERC-20 and ERC-721. -KIP-7 and KIP-17 are based on ERC-20 and ERC-721, but they are tailored for Klaytn and thus more suitable on Klaytn ecosystem. Yet ERC-20 and ERC-721 are still supported on Klaytn network, they may not be compatible with various tools in Klaytn ecosystem. -For more information about the differences on token standards, please visit [KIP-7](https://kips.kaia.io/KIPs/kip-7#differences-with-erc-20) and [KIP-17](https://kips.kaia.io/KIPs/kip-17#differences-from-erc-721). +カイアはトークン標準としてKIP-7とKIP-17を公表しているため、ERC-20とERC-721に従うのではなく、それぞれKIP-7とKIP-17に従ってファンジブルとノンファンジブルのトークンコントラクトを実装することが推奨される。 +KIP-7とKIP-17はERC-20とERC-721をベースにしているが、カイア用に調整されているため、カイアのエコシステムにより適している。 ERC-20とERC-721はまだカイアのネットワークでサポートされているが、カイアのエコシステムの様々なツールとは互換性がないかもしれない。 +トークン規格の違いについては、[KIP-7](https://kips.kaia.io/KIPs/kip-7#differences-with-erc-20)、[KIP-17](https://kips.kaia.io/KIPs/kip-17#differences-from-erc-721)をご覧ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md index ba695b2442da..5b849f4ef7fc 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md @@ -1,34 +1,34 @@ --- -sidebar_label: Using Block Explorers +sidebar_label: ブロック・エクスプローラーを使う --- -# How to verify Smart Contracts Using Block Explorers +# ブロックエクスプローラーを使ったスマートコントラクトの検証方法 -## Introduction +## はじめに -Usually, the deployer of a smart contract is the only party with access to the code that was actually deployed, and the public cannot read the source code of a contract until the deployer has verified it. However, this is where contract verification comes in as an important step in the smart-contract development cycle, as it helps improve the transparency (for users), convenience (for developers), and security of deployed contracts. +通常、スマート・コントラクトのデプロイ者は、実際にデプロイされたコードにアクセスできる唯一の当事者であり、デプロイ者が検証するまで、一般人はコントラクトのソースコードを読むことができない。 コントラクトの検証は、（ユーザーにとっての）透明性、（開発者にとっての）利便性、そしてデプロイされたコントラクトの安全性を向上させるのに役立つからだ。 -Having said that, once a smart contract is validated, block explorers like Kaiascope and Kaiascan also make it possible for the public to interact with the contract's public methods using the block explorer's user interface. This is in addition to the public having direct access to the verified contract source code. +とはいえ、スマート・コントラクトが検証されると、KaiascopeやKaiascanのようなブロック・エクスプローラーは、ブロック・エクスプローラーのユーザー・インターフェースを使用して、一般の人がコントラクトのパブリック・メソッドと対話することも可能にする。 これは、一般の人々が検証済みの契約ソースコードに直接アクセスできることに加えてのことである。 -In this guide, we'll take a look at how to use block explorers to verify deployed smart contracts on the Klaytn Network. +このガイドでは、ブロックエクスプローラーを使用してKaiaネットワーク上でデプロイされたスマートコントラクトを検証する方法を見ていきます。 -## Prerequisites +## 前提条件 -- [Remix IDE](https://ide.kaia.io/) and [Kaia Wallet](https://docs.kaiawallet.io/getting_started/quick_start#install-kaia-wallet) -- Enough test KAIA from [faucet](https://faucet.kaia.io) +- [Remix IDE](https://ide.kaia.io/) と [Kaia Wallet](https://docs.kaiawallet.io/getting_started/quick_start#install-kaia-wallet) +- [Faucet](https://faucet.kaia.io)から十分なテストKAIA -## Getting Started +## はじめに -In this guide, we will be going over verifying both single contracts and multi-part contracts on the block explorers that exist in the Klaytn ecosystem, viz.: +このガイドでは、Kaiaエコシステムに存在するブロックエクスプローラーで、シングルコントラクトとマルチパートコントラクトの検証について説明します： -- [Kaiascope](https://kaiascope.com/) -- [Kaiascan](https://www.kaiascan.io/) +- [カイアスコープ](https://kaiascope.com/) +- [カイアスカン](https://www.kaiascan.io/) -Without further ado, let's get started! +さっそく始めよう！ -## Deploying a single Contract +## 単一契約の展開 -To verify a smart contract, you need to deploy the contract first on the target network. Hence, for the sake of this guide, we will be deploying the contract to Klaytn Baobab Testnet. Also, in this tutorial, we will be deploying a simple counter contract named `Counter.sol` on Remix IDE. The code is shown below: +スマート・コントラクトを検証するには、まずターゲット・ネットワーク上にコントラクトをデプロイする必要がある。 したがって、このガイドでは、Kaia Kairos Testnetにコントラクトをデプロイすることにする。 また、このチュートリアルでは、Remix IDE上に`Counter.sol`というシンプルなカウンターのコントラクトをデプロイする。 コードを以下に示す： ```solidity // SPDX-License-Identifier: MIT @@ -52,35 +52,35 @@ contract Counter { :::note -You can check this page for a tutorial on deploying smart contracts using [libraries](../../../references/sdk/sdk.md) on Klaytn Baobab Testnet. You may also use a developer tool such as [Hardhat](../../get-started/hardhat.md), [Foundry](../deploy/foundry.md), [Remix](../deploy/deploy.md#remix-ide) or another tool if preferred, to deploy the smart contract to Klaytn Baobab Testnet. +Kaia Kairos Testnetの[libraries](../../../references/sdk/sdk.md)を使ったスマートコントラクトのデプロイに関するチュートリアルは、このページで確認できます。 スマートコントラクトをKaia Kairos Testnetにデプロイするには、[Hardhat](../../get-started/hardhat.md)、[Foundry](../deploy/foundry.md)、[Remix](../deploy/deploy.md#remix-ide)などの開発者ツールを使用することもできます。 ::: -## Parameters for single contract verification +## 単一契約検証のパラメータ -Verifying a contract on the block explorers requires some parameters, and these must be considered while deploying the smart contract. The following are some details related to the contract's compiler and deployment in order to verify a contract successfully: +ブロック・エクスプローラーでコントラクトを検証するには、いくつかのパラメータが必要で、スマート・コントラクトをデプロイする際に考慮しなければならない。 以下は、コントラクトをうまく検証するための、コントラクトのコンパイラとデプロイメントに関する詳細である： Remix IDE : -- On Remix IDE, navigate to the **Solidity compiler tab**. +- Remix IDEで、**Solidityコンパイラタブ**に移動します。 - - Observe the **compiler version** used to compile and deploy the contract. - - Observe the **Open Source License Type** used in the contract. This means the SPDX license identifier used at the beginning of the Solidity source file. In the `Counter.sol` file we used `// SPDX-License-Identifier: MIT` - - Observe the **EVM version** used for deploying contracts. - - (Optional) If **optimization** is enabled during compilation, take note of the value of the optimization runs parameter + - 契約のコンパイルとデプロイに使用された**コンパイラのバージョン**を確認してください。 + - 契約で使用されている**オープンソースライセンスの種類**を確認してください。 これは、Solidity ソース ファイルの先頭で使用される SPDX ライセンス識別子を意味します。 `Counter.sol`ファイルでは、`// SPDX-License-Identifier：MIT` + - コントラクトのデプロイに使用される**EVMバージョン**を確認してください。 + - (オプション）コンパイル時に**最適化**が有効になっている場合、最適化実行パラメータの値に注意する。 ![](/img/build/tutorials/counter-veri-parameters.png) -- On Remix IDE, navigate to **Klaytn tab**. +- Remix IDEで**Kaiaタブ**に移動します。 - - (Optional) If the contract constructor method accepts arguments, take note of the [ABI-encoded form](https://docs.soliditylang.org/en/develop/abi-spec.html) of the constructor arguments - - Take note of the contract address of the smart contract on the **Deployed Contracts** tab after successful deployment. + - (オプション) コンストラクタのメソッドが引数を受け付ける場合は、コンストラクタの引数の [ABI エンコード形式](https://docs.soliditylang.org/en/develop/abi-spec.html) に注意してください。 + - デプロイに成功したら、**Deployed Contracts**タブでスマートコントラクトのコントラクトアドレスをメモしてください。 ![](/img/build/tutorials/counter-veri-parametersII.png) -## Deploying a multi-part contract +## マルチパート契約の展開 -It is important to note that deploying a multi-part contract involves the same steps as deploying a single contract. For the sake of this guide, we will be deploying a simple KIP7 airdrop contract named `airdropToken.sol`. The code is shown below: +マルチパートのコントラクトのデプロイメントには、単一のコントラクトのデプロイメントと同じ手順が必要であることに注意することが重要である。 このガイドでは、`airdropToken.sol`という名前のシンプルなKIP7のエアドロップ契約をデプロイする。 コードを以下に示す： ```solidity //SPDX-License-Identifier: MIT @@ -114,86 +114,86 @@ contract TokenAirdrop is KIP7, Ownable { } ``` -## Parameters for multi-part contract verification +## マルチパート契約検証のパラメータ -The parameters for verifying a multi-part contract are the same as those for a single contract. However, because they are made up of multiple dependent contracts, we need to pre-process all dependencies of the contract into a single solidity file. This preprocessing is usually referred to as smart contract flattening. +マルチパート契約を検証するためのパラメータは、単一契約の場合と同じである。 しかし、それらは複数の依存するコントラクトで構成されているため、コントラクトのすべての依存関係を単一のsolidityファイルに前処理する必要があります。 この前処理は通常、スマート・コントラクトのフラット化と呼ばれる。 -For this reason, we will have to flatten the contract so it can be verified using the new flattened Solidity file on the block explorer. +このため、コントラクトをフラット化し、ブロックエクスプローラーで新しいフラット化されたSolidityファイルを使用して検証できるようにする必要があります。 Remix IDE: -- On Remix IDE, navigate to the **File explorer tab**. +- Remix IDEで、**ファイルエクスプローラタブ**に移動します。 - - Select the newly created contract under the **contracts** folder - - Click or tap with two fingers to see all commands available on the contract. - - Select **flatten** + - **contracts**フォルダの下に新しく作成した契約を選択します。 + - 2本指でクリックまたはタップすると、契約で利用可能なすべてのコマンドが表示されます。 + - **flatten**を選択 ![](/img/build/tutorials/airdropToken-flattened.png) - - Once code is flattened, you will see a new contract named `airdropTokens_flattened.sol`. + - コードが平坦化されると、`airdropTokens_flattened.sol`という名前の新しいコントラクトが表示されます。 ![](/img/build/tutorials/airdropToken-flattened-file.png) :::note -There are different tools for flattening a multi-part smart contract into a single Solidity file, such as [Hardhat Flattener](https://hardhat.org/hardhat-runner/docs/advanced/flattening). Kindly refer to the respective smart contract flattening tool's documentation for more detailed instructions on its usage. +マルチパートのスマートコントラクトを単一のSolidityファイルにフラット化するためのさまざまなツールがあります。たとえば、[Hardhat Flattener](https://hardhat.org/hardhat-runner/docs/advanced/flattening)があります。 スマート・コントラクト・フラットニング・ツールの詳細な使用方法については、それぞれのスマート・コントラクト・フラットニング・ツールのドキュメントを参照してください。 ::: -## Verifying the Contract +## 契約の確認 -Having obtained all of our verification parameters, we will go over the steps for verifying a single smart contract (Counter.sol) and a multi-part smart contract (airdropTokens.sol) on the block explorer in this section. +検証パラメータをすべて取得したので、このセクションでは、ブロック・エクスプローラ上で単一のスマート・コントラクト（Counter.sol）と複数パートのスマート・コントラクト（airdropTokens.sol）を検証する手順を説明します。 -### 1. Klaytnscope +### 1. Kaiascope -To verify a single contract and multi-part contracts on Klaytnscope, follow the steps below: +Kaiascopeで単一契約および複数パート契約を検証するには、以下の手順に従ってください： -#### 1.1 Verifying a single contract +#### 1.1 単一契約の検証 -1. Goto the search bar of [Kaiascope](https://kairos.kaiascope.com) and paste the deployed contract address. -2. Navigate to the **contract tab** on that page. -3. Click on the **Match Contract Source Code** link to submit contract code for verification. +1. [Kaiascope](https://kairos.kaiascope.com)の検索バーに、デプロイされた契約書のアドレスを貼り付ける。 +2. そのページの**契約タブ**に移動する。 +3. **Match Contract Source Code** リンクをクリックして、確認のために契約コードを送信します。 ![](/img/build/tutorials/counter-contract-tab.png) -4. On the contract verification page, make sure your account is connected to either Kaia Wallet or Metamask. For this guide, we will be using Kaia Wallet. -5. Fill in the contract address in the **contract address field**. Note: This field is usually filled with the contract address automatically. -6. Select the **compiler version** used for the `Counter.sol` example. -7. Select the **Open Source License Type** used for the `Counter.sol` example. For `Counter.sol` example, select the option, **MIT License (MIT)**. If there was none used, select **No License (None)**. -8. In the **Source Code field**, select **Source Text** and paste the source code for `Counter.sol` in the text-field. -9. Select **True** for **Optimization** if it was enabled during compilation, and fill in the number of runs under **Optimization Runs** to be **200**. -10. Select the **EVM version** for the contract. For `Counter.sol` example, select the option **Istanbul**. -11. Click on the CAPTCHA at the bottom and the **Sign and Submit** button to confirm and begin verification. +4. 契約確認ページで、アカウントがKaia WalletまたはMetamaskのいずれかに接続されていることを確認します。 このガイドでは、カイア・ウォレットを使用します。 +5. 契約住所欄\*\*に契約住所を記入する。 注：このフィールドには通常、契約住所が自動的に入力されます。 +6. `Counter.sol`の例で使用した**コンパイラのバージョン**を選択する。 +7. `Counter.sol`の例で使用した**オープン・ソース・ライセンス・タイプ**を選択します。 Counter.solの例では、\*\*MIT License (MIT)\*\*を選択してください。 使用されていない場合は、\*\*ライセンスなし（None）\*\*を選択します。 +8. **Source Code field**で、**Source Text**を選択し、テキストフィールドに`Counter.sol`のソースコードを貼り付けます。 +9. **最適化**がコンパイル時に有効になっている場合は**True**を選択し、**Optimization Runs**の実行回数を**200**になるように入力します。 +10. 契約の**EVMバージョン**を選択します。 `Counter.sol`の例では、**Istanbul**を選択する。 +11. 下部のCAPTCHAと**Sign and Submit**ボタンをクリックして確認し、認証を開始します。 ![](/img/build/tutorials/counter-verification-page.png) -12. After signing the verification request, you will get a verification status notification +12. 検証リクエストに署名した後、検証ステータスの通知が届きます。 ![](/img/build/tutorials/counter-success-popup.png) -13. Once verification is done, the result of the verification will be displayed in the browser, and a success result page with the contract address. Click on the contract address to view the **Contract Source Code**, **Contract ABI**, and **Bytecode**. +13. 検証が完了すると、検証結果がブラウザに表示され、契約先が記載された成功結果ページが表示される。 契約アドレスをクリックすると、**契約ソースコード**、**契約ABI**、**バイトコード**が表示されます。 ![](/img/build/tutorials/counter-success-popup-I.png) ![](/img/build/tutorials/counter-full-verification.png) -#### 1.2 Verifying multi-part contract +#### 1.2 複数パート契約の検証 -Verifying a multi-part contract on Klaytnscope is as straightforward as verifying a single contract, except that it requires some additional steps. In this section, we will be verifying the `airdropToken.sol` contract with the following additional steps: +Kaiascopeでの複数パート契約の検証は、いくつかの追加ステップが必要なことを除けば、単一契約の検証と同じくらい簡単です。 このセクションでは、`airdropToken.sol`コントラクトを以下のステップを追加して検証する： -- You can either Select **Source Text** under **Source Code** (step 3 of the Counter.sol example) or **Solidity File(s)** under the **Source Code** field. In the case of **Source Text**, copy the code in the `airdropToken_flattened.sol` and paste in the text field. If **Solidity File(s)**, you can download the `airdropToken_flattened.sol` file on Remix IDE and upload to the field. +- ソースコード**の下にある**ソーステキスト\*\*(Counter.solの例のステップ3)、または**ソースコード**フィールドの下にある\*\*ソリディティファイル(s)\*\*を選択することができます。 **Source Text**の場合、`airdropToken_flattened.sol`内のコードをコピーしてテキストフィールドに貼り付けます。 \*\*Solidity File(s)\*\*の場合、Remix IDEで`airdropToken_flattened.sol`ファイルをダウンロードし、フィールドにアップロードします。 -a. Source Text +a. ソース・テキスト ![](/img/build/tutorials/airdrop-veri-field-I.png) -b. Solidity File(s) +b. ソリディティファイル ![](/img/build/tutorials/airdrop-veri-field-II.png) -After this, every other step remains the same as verifying a single contract. Having filled the verification parameter, click on the **Sign and Submit** button to confirm and begin verification. +この後、他のすべてのステップは、単一の契約を検証するのと同じである。 検証パラメータを入力したら、**Sign and Submit** ボタンをクリックして確認し、検証を開始します。 -Once verification is done, the result of the verification will be displayed in the browser, and a success result page with the contract address. Click on the contract address to view the **Contract Source Code**, **Contract ABI**, and **Bytecode**. +検証が完了すると、検証結果がブラウザに表示され、契約先が記載された成功結果ページが表示される。 契約アドレスをクリックすると、**契約ソースコード**、**契約ABI**、**バイトコード**が表示されます。 ![](/img/build/tutorials/airdrop-success-popup.png) @@ -201,27 +201,27 @@ Once verification is done, the result of the verification will be displayed in t ![](/img/build/tutorials/airdrop-full-verification.png) -### 2. Kaiascan +### 2. カイアスカン To verify a single contract and multi-part contracts on Kaiascan, navigate to the [contract submission request page](https://kairos.kaiascan.io/contracts). :::note -Verification of contracts on Kaiascan is currently in beta. +Kaiascanでの契約の検証は現在ベータ版です。 ::: ![](/img/build/tutorials/kaiascan-con-sub-page.png) -#### 2.1 Verifying single contract +#### 2.1 単一契約の検証 -1. Fill in the **contract address** for the deployed contract (Counter.sol) -2. Select the **compiler version** used for the `Counter.sol` example -3. Select the **Open Source License Type** used for the `Counter.sol` example. For `Counter.sol` example, select the option, **MIT License (MIT)**. If there was none used, select **No License (None)** -4. Make sure to download `Counter.sol` from Remix IDE and upload in the **Source Code (Solidity File)** field -5. Select the **EVM version** for the contract. For `Counter.sol` example, select the option **Istanbul**. -6. Select **True** for **Optimization** if it was enabled during compilation, and fill in the number of runs under **Optimization Runs** to be **200**. -7. (optional) To get the ABI-encoded constructor arguments for this field, navigate to [abi.hashex.org](http://abi.hashex.org) to get the encoded data following the image below: +1. 配置された契約（Counter.sol）の**契約アドレス**を記入してください。 +2. `Counter.sol`の例で使用されている**コンパイラのバージョン**を選択してください。 +3. `Counter.sol`の例で使用した**オープン・ソース・ライセンス・タイプ**を選択します。 Counter.solの例では、\*\*MIT License (MIT)\*\*を選択してください。 使用されたものがない場合は、\*\*ライセンスなし（None）\*\*を選択する。 +4. 必ずRemix IDEから`Counter.sol`をダウンロードし、\*\*Source Code (Solidity File)\*\*フィールドにアップロードしてください。 +5. 契約の**EVMバージョン**を選択します。 `Counter.sol`の例では、**Istanbul**を選択する。 +6. **最適化**がコンパイル時に有効になっている場合は**True**を選択し、**Optimization Runs**の実行回数を**200**になるように入力します。 +7. (オプション) このフィールドのABIエンコードされたコンストラクタ引数を取得するには、[abi.hashex.org](http://abi.hashex.org) にアクセスして、以下の画像に従ってエンコードされたデータを取得します： ![](/img/build/tutorials/abi-hashex.png) @@ -229,20 +229,20 @@ Verification of contracts on Kaiascan is currently in beta. ![](/img/build/tutorials/counter-k-verification-page.png) -9. Once verification is done, you will get a **Submission Successful** message. Now you can paste the contract address in the explorer search bar to view the **Contract Source Code**, **Contract ABI**, **Creation Code** and **ABI-encoded Value**. +9. 認証が完了すると、**Submission Successful**というメッセージが表示されます。 これで、エクスプローラーの検索バーに契約書アドレスを貼り付けて、**契約書ソースコード**、**契約書ABI**、**作成コード**および**ABIエンコード値**を表示できる。 > ![](/img/build/tutorials/counter-k-full-verification.png) -### 2.2 Verifying multiple-part contract +### 2.2 複数パート契約の検証 -Verifying a multi-part contract on Kaiascan follows the same step as verifying a single contract. However, it is important to note we will be uploading the `airdropToken_flattened.sol` file in the **Source Code(Solidity File)** field. +Kaiascanで複数パートにまたがる契約を検証する場合は、単一の契約を検証する場合と同じ手順を踏みます。 ただし、Kaiascan は現在検証用ファイルのアップロードをサポートしていないため、`airdropToken_flattened.sol` ファイルをコピーして **Enter the Solidity Contract Code below** フィールドに貼り付けることに注意してください。 ![](/img/build/tutorials/airdrop-k-verification-page.png) -After filling the verification parameters, click on the **Sign and Submit** button to confirm and begin verification. Once verification is done, the verification page will refresh. Now you can paste the contract address in the explorer search bar to view the **Contract Source Code**, **Contract ABI**, and **Creation Code**. +検証パラメータを入力したら、**Verify and Publish** ボタンをクリックして検証を開始します。 認証が完了すると、認証ページが更新されます。 これで、エクスプローラーの検索バーに契約書のアドレスを貼り付けて、**契約書のソースコード**、**契約書のABI**、**作成コード**を表示できる。 ![](/img/build/tutorials/airdrop-k-full-verification.png) -## Conclusion +## 結論 -Congratulations on following this guide! In this tutorial, you learnt how to verify contracts (both single and multi-part) using Kaiascope and Kaiascan solely to enhance the transparency (for users), convenience (for developers), and security of deployed contracts. Visit [Kaia Docs](https://docs.klaytn.foundation/) for more information and [Kaia Forum](https://devforum.kaia.io/) if you have any questions. +このガイドに従ったことを祝福する！ このチュートリアルでは、KaiascopeとKaiascanのみを使用してコントラクト（シングル・パートとマルチ・パートの両方）を検証し、（ユーザーにとっての）透明性、（開発者にとっての）利便性、およびデプロイされたコントラクトの安全性を高める方法を学びました。 より詳しい情報は[Kaia Docs](https://docs.kaia.io/)を、質問があれば[Kaia Forum](https://devforum.kaia.io/)をご覧ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md index f2704521359f..f776365d0fbe 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md @@ -1,14 +1,14 @@ --- -sidebar_label: Using Hardhat +sidebar_label: ハードハットの使用 --- -# How to Verify Smart Contracts Using Hardhat +# Hardhatを使用してスマートコントラクトを検証する方法 This guide allows you to automatically verify your smart contracts' source code on Klaytnscope straight from your CLI using the Hardhat Verify Plugin. -To verify your contract on klaytn, you need to add the following configuration to your `hardhat.config.js`: +klaytnでの契約を確認するには、`hardhat.config.js`に以下の設定を追加する必要があります： -## Mainnet +## メインネット ``` module.exports = { @@ -37,35 +37,35 @@ module.exports = { ``` -## Kairos +## カイロス ``` module.exports = { - networks: { + networks：{ kairos: { - chainId: 1001, - url: "RPC_URL", + chainId：1001, + url："RPC_URL", }, }, - etherscan: { - apiKey: { + etherscan：{ + apiKey：{ kairos: "unnecessary", }, - customChains: [ + customChains：[ { - network: "kairos", - chainId: 1001, - urls: { - apiURL: "https://api-baobab.klaytnscope.com/api", - browserURL: "https://kairos.kaiascope.com", + network："kairos", + chainId：1001, + urls：{ + apiURL："https://api-baobab.klaytnscope.com/api", + browserURL："https://kairos.kaiascope.com", }, }, - ] + ]。 } } ``` -To verify the contract, you will run the verify command and pass in the address of the deployed contract, network and parameters if any. +コントラクトを検証するには、verifyコマンドを実行し、デプロイされたコントラクトのアドレス、ネットワーク、パラメータがあればそれを渡す。 ```bash npx hardhat verify –network @@ -75,13 +75,13 @@ npx hardhat verify –network npx hardhat verify --network klaytn 0x131b54E65c99d34BCA738F29051fDAceEa91C969 1000000000000000 ``` -In your terminal you should see the source code for your contract was successfully submitted for verification. If the verification was successful, you should see Successfully verified contract and there will be a link to the contract code on [Kaiascope](https://kairos.kaiascope.com/account/0x131b54E65c99d34BCA738F29051fDAceEa91C969?tabId=contractCode). +ターミナルに、契約のソースコードが検証のために正常に送信されたことが表示されるはずです。 検証が成功した場合、[Successfully verified contract]と表示され、[Kaiascope](https://kairos.kaiascope.com/account/0x131b54E65c99d34BCA738F29051fDAceEa91C969?tabId=contractCode)に契約コードへのリンクが表示されます。 ![](/img/build/smart-contracts/verify/terminal-hh-verify-ss.png) ![](/img/build/smart-contracts/verify/scope-hh-verify-ss.png) -## Useful links +## お役立ちリンク -- [Configuration for Hardhat Verify Plugin](https://docs.klaytnscope.com/contract/configuration-for-hardhat-verify-plugin) +- [Hardhat Verifyプラグインの設定](https://docs.klaytnscope.com/contract/configuration-for-hardhat-verify-plugin) - [Verifying contracts using Hardhat on Klaytnscope](https://klaytn.foundation/verifying-contracts-using-hardhat-on-klaytnscope) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.mdx new file mode 100644 index 000000000000..7eb5ab059d8e --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.mdx @@ -0,0 +1,151 @@ +--- +id: hardhat +title: Using Hardhat +--- + +import Tabs from '@theme/Tabs' +import TabItem from '@theme/TabItem' + +# How to Verify Smart Contracts Using Hardhat + +This guide allows you to automatically verify your smart contracts' source code on Kaiascope straight from your CLI using the Hardhat Verify Plugin. + +To verify your contract on Kaia, you need to add the following configuration to your `hardhat.config.js`: + +## Kaiascan + + + + ```js + module.exports = { + etherscan: { + apiKey: { + kaia: "unnecessary", + }, + customChains: [ + { + network: "kaia", + chainId: 8217, + urls: { + apiURL: "https://mainnet-api.kaiascan.io/hardhat-verify", + browserURL: "https://kaiascan.io", + } + }, + ] + } + } + ``` + + + + ```js + module.exports = { + etherscan: { + apiKey: { + kairos: "unnecessary", + }, + customChains: [ + { + network: "kairos", + chainId: 1001, + urls: { + apiURL: "https://kairos-api.kaiascan.io/hardhat-verify", + browserURL: "https://kairos.kaiascan.io", + } + }, + ] + } + } + ``` + + + +## Kaiascope + + + + ```js + module.exports = { + networks: { + kaia: { + chainId: 8217, + url: "RPC_URL", + }, + }, + etherscan: { + apiKey: { + kaia: "unnecessary", + }, + customChains: [ + { + network: "kaia", + chainId: 8217, + urls: { + apiURL: "https://api-cypress.klaytnscope.com/api", + browserURL: "https://kaiascope.com/", + }, + }, + ] + } + } + ``` + + + + ```js + module.exports = { + networks: { + kairos: { + chainId: 1001, + url: "RPC_URL", + }, + }, + etherscan: { + apiKey: { + kairos: "unnecessary", + }, + customChains: [ + { + network: "kairos", + chainId: 1001, + urls: { + apiURL: "https://api-baobab.klaytnscope.com/api", + browserURL: "https://kairos.kaiascope.com", + }, + }, + ] + } + } + ``` + + + +To verify the contract, you will run the verify command and pass in the address of the deployed contract, network and parameters if any. + +```bash +npx hardhat verify –network + +// example + +npx hardhat verify --network kairos 0x3e360fC99c4383e3adaAE9742c0fC983fDAa0535 +``` + +In your terminal you should see the source code for your contract was successfully submitted for verification. + +If the verification was successful, you should see Successfully verified contract and there will be a link to the contract code on [Kaiascan](https://kairos.kaiascan.io/address/0x3e360fC99c4383e3adaAE9742c0fC983fDAa0535?tabId=contract\&page=1) and [Kaiascope](https://baobab.klaytnscope.com/account/0x3e360fC99c4383e3adaAE9742c0fC983fDAa0535?tabId=contractCode) respectively. + +**Kaiascan** + +![](/img/build/smart-contracts/verify/kaiascan-terminal.png) +![](/img/build/smart-contracts/verify/kaiascan-verify.png) + +**Kaiascope** + +![](/img/build/smart-contracts/verify/kaiascope-terminal.png) +![](/img/build/smart-contracts/verify/kaiascope-verify.png) + +## Useful links + +* [Configuration for Hardhat Verify Plugin on Kaiascan](https://docs.kaiascan.io/hardhat-verify) +* [Configuration for Hardhat Verify Plugin on Kaiascope](https://docs.klaytnscope.com/contract/configuration-for-hardhat-verify-plugin) +* [Verifying contracts using Hardhat on Kaiascan](https://klaytn.foundation/verifying-contracts-using-hardhat-on-klaytnscope) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md index 9ed31a265f6e..4bdda3ca88b9 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md @@ -1,18 +1,18 @@ --- -sidebar_label: Using Sourcify +sidebar_label: Sourcifyの使用 --- -# How to Verify Smart Contracts Using Sourcify +# Sourcifyを使用してスマートコントラクトを検証する方法 -[Sourcify](sourcify.dev) is a Solidity (smart contracts) source code verification service for Ethereum and EVM-compatible chains like Kaia. One of its unique features is that it leverages the [Solidity metadata](https://docs.sourcify.dev/docs/metadata/) file to ["fully verify"](https://docs.sourcify.dev/docs/full-vs-partial-match/) the contracts. +[Sourcify](sourcify.dev)は、イーサリアムとKaiaのようなEVM互換チェーンのためのSolidity（スマートコントラクト）ソースコード検証サービスです。 そのユニークな特徴の 1 つは、[Solidity メタデータ](https://docs.sourcify.dev/docs/metadata/) ファイルを活用してコントラクトを [完全に検証](https://docs.sourcify.dev/docs/full-vs-partial-match/) することです。 -In this guide, we'll take a look at how to verify a smart contract on Foundry using Sourcify.  +このガイドでは、Sourcifyを使用してFoundry上でスマートコントラクトを検証する方法を見ていきます。 -## Getting started +## スタート -This guide expects that you have an idea of developing smart contracts with Foundry. See [Deploy smart contract using Foundry](../deploy/foundry.md) to get started. Foundry provides native support for Sourcify verification—all you need to do is add a few flags to your forge command. To verify contracts with Sourcify using Foundry, see the steps below: +このガイドでは、Foundryを使用したスマートコントラクトの開発について理解していることを想定しています。 Foundryを使用したスマートコントラクトのデプロイ](../deploy/foundry.md)をご覧ください。 FoundryはSourcify検証のネイティブサポートを提供しています。必要なのは、forgeコマンドにいくつかのフラグを追加するだけです。 Foundryを使用してSourcifyとの契約を確認するには、以下の手順を参照してください： -## Deploy and verify a contract: +## 契約を展開し、検証する： ```bash /* deploy */ @@ -30,11 +30,11 @@ forge verify-contract 0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2 src/Counter.sol ![](/img/build/smart-contracts/verify/sourcify-verify.png) -You can look up the verified contract [here](https://sourcify.dev/#/lookup/0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2) +確認された契約書は[こちら](https://sourcify.dev/#/lookup/0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2)で調べることができる。 ![](/img/build/smart-contracts/verify/sourcify-lookup-verify.png) -## Check if a contract is verified +## 契約が確認されているかどうかをチェックする ```bash forge verify-check 0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2 --chain-id 1001 --verifier sourcify @@ -42,10 +42,10 @@ forge verify-check 0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2 --chain-id 1001 -- ![](/img/build/smart-contracts/verify/sourcify-verify.png) -## Useful links +## お役立ちリンク -- [Sourcify Verifier](https://sourcify.dev/#/verifier) -- [Using Sourcify UI Verification](https://docs.sourcify.dev/docs/how-to-verify/#using-the-ui-legacy) -- [Verifying on Hardhat with Sourcify](https://docs.sourcify.dev/docs/how-to-verify/#hardhat) -- [Verifying on Remix using Sourcify](https://docs.sourcify.dev/docs/how-to-verify/#remix-plugin) +- [ソーシファイの検証者](https://sourcify.dev/#/verifier) +- [Sourcify UI検証の使用](https://docs.sourcify.dev/docs/how-to-verify/#using-the-ui-legacy) +- [Sourcifyを使ったハードハットでの検証](https://docs.sourcify.dev/docs/how-to-verify/#hardhat) +- [Sourcifyを使ったRemixでの検証](https://docs.sourcify.dev/docs/how-to-verify/#remix-plugin) - [Sourcify Playground](https://playground.sourcify.dev/) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md index 187ac9075c7c..b01a3360b2e2 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md @@ -1,9 +1,9 @@ -# Block Explorers +# ブロック探検隊 -This blockchain tool enables users and enthusiasts to search for real-time and historical information about the blockchain. Block explorers on Klaytn contain information about Klaytn, and as such, users can search for blocks, transactions, balances, addresses, and contracts on Klaytn. +このブロックチェーン・ツールは、ユーザーや愛好家がブロックチェーンに関するリアルタイムおよび過去の情報を検索することを可能にする。 カイアのブロックエクスプローラーにはカイアに関する情報が含まれており、ユーザーはカイアのブロック、取引、残高、アドレス、契約を検索することができます。 -The list of explorers supported by Klaytn is provided below: +カイアがサポートするエクスプローラのリストは以下の通りです： -- [Kaiascope](https://kaiascope.com/) -- [Kaiascan](https://www.kaiascan.io/) -- [OKX Kaia Explorer](https://www.okx.com/web3/explorer/kaia) +- [カイアスコープ](https://kaiascope.com/) +- [カイアスカン](https://www.kaiascan.io/) +- [OKX カイア・エクスプローラー](https://www.okx.com/web3/explorer/kaia) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md index e4cf89d30e12..074f9b3f4d3c 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md @@ -1,230 +1,230 @@ # Kaiascope -Kaiascope is the block explorer for the Kaia Network. Kaiascope gives you an insight about the Kaia network by monitoring the network health and providing various statistics of Kaia network. You can also explore the block and transaction data and the list of smart contracts on the Kaia network. +Kaiascopeはカイアネットワークのブロックエクスプローラーです。 Kaiascopeは、ネットワークの健全性を監視し、Kaiaネットワークの様々な統計情報を提供することで、Kaiaネットワークに関する洞察力を提供します。 また、ブロックや取引データ、カイアネットワーク上のスマートコントラクトのリストを調べることもできる。 -- For the Kairos network, visit [https://kairos.kaiascope.com](https://kairos.kaiascope.com) -- For the Mainnet, visit [https://kaiascope.com/](https://kaiascope.com/) +- カイロス・ネットワークについては、[https://kairos.kaiascope.com](https://kairos.kaiascope.com) をご覧ください。 +- メインネットについては、[https://kaiascope.com/](https://kaiascope.com/) をご覧ください。 ![](/img/build/tools/scope_01_main.png) -## Major Features +## 主な特徴 -Please note that some of the features are under development. +一部の機能は開発中です。 -- Overview of the network -- Block search -- Transaction search -- Account search -- Event logs search -- Block proposer information +- ネットワークの概要 +- ブロック検索 +- トランザクション検索 +- アカウント検索 +- イベントログ検索 +- ブロック提案者情報 -In the subsequent sections, we will visit the major functions and screenshots of Kaiascope. Functions are grouped by four categories - dashboard, list view, detail view, and search. +次のセクションでは、Kaiascopeの主な機能とスクリーンショットを紹介します。 機能は、ダッシュボード、リスト表示、詳細表示、検索の4つのカテゴリーに分類されている。 -## Dashboard +## ダッシュボード -Network information is presented in the dashboard. The information includes average block generation time, average number of transactions in a block, number of consensus nodes, and the latest trends in transactions. +ネットワーク情報はダッシュボードに表示される。 この情報には、平均ブロック生成時間、ブロック内の平均トランザクション数、コンセンサスノード数、トランザクションの最新トレンドなどが含まれる。 ![](/img/build/tools/scope_02_main_indicator.png) -- Block Height: The latest block height. It shows that how many blocks have been generated since the genesis. -- Network Performance: It shows Kaia's network performance with four indicators. - - Consensus Nodes: Above picture shows that 15 nodes are participated in the consensus process. - - Avg Block Time \(1 hour\): It shows the average block generation time over the last hour. - - Avg Block Time \(24 hours\): It shows the average block generation time over the last 24 hours. - - Avg TX Per Block \(24 hours\): The average number of transactions included in one block over the last 24 hours. -- Transaction History \(14 days\): The graphs show the number of daily transactions over the last 14 days. You can see the trend in the transaction volume over the last two weeks. +- ブロックの高さ最新のブロックの高さ。 これは、創世記から何個のブロックが生成されたかを示している。 +- ネットワーク・パフォーマンス：カイアのネットワーク・パフォーマンスを4つの指標で示す。 + - コンセンサスノード：上の図は、15ノードがコンセンサスプロセスに参加していることを示している。 + - Avg Block Time ￤1時間：過去1時間の平均ブロック生成時間を示す。 + - Avg Block Time \(24 hours)：過去24時間の平均ブロック生成時間を示す。 + - Avg TX Per Block \(24 hours\)：過去24時間の1ブロックに含まれるトランザクションの平均数。 +- 取引履歴(14日)：過去14日間の取引履歴です。 過去2週間の取引量の推移を見ることができる。 -### Recent Blocks & Transactions +### 最近のブロックと取引 -These lists show recently created blocks and transactions respectively. You can get the latest information by clicking the refresh button on the upper-right corner in the pane. In the bottom of the list, clicking the ‘view all’ button will take you to the [list view](#list-view). +これらのリストには、最近作成されたブロックとトランザクションがそれぞれ表示される。 ペインの右上隅にある更新ボタンをクリックすれば、最新の情報を得ることができる。 リストの一番下にある'view all'ボタンをクリックすると、[リスト表示](#list-view)になります。 ![](/img/build/tools/scope_03_main_list.png) -### Network Status & Network Selector +### ネットワーク・ステータス＆ネットワーク・セレクター ![](/img/build/tools/network_status.gif) -On the upper-right corner of the site, there are network status indicator and the network selector drop down. +サイトの右上には、ネットワーク・ステータスのインジケータとネットワーク・セレクタのドロップダウンがある。 -- Network Status Indicator - - Network is healthy: Kaiascope is healthy and fully operational. The network status is normal. - - Data latency: Kaiascope is undergoing system maintenance. Data is in a delayed state. - - Data accuracy: Kaiascope is synchronizing data, please wait. -- Network Selector Drop Down - - You can choose Kaia mainnet and Kairos testnet from the menu. +- ネットワーク・ステータス・インジケータ + - ネットワークは健全：Kaiascopeは健全で完全に稼働している。 ネットワークの状態は正常です。 + - データ遅延：Kaiascopeはシステムメンテナンス中です。 データは遅延状態にある。 + - データの精度Kaiascopeはデータを同期しています。 +- ネットワーク選択ドロップダウン + - メニューからKaia mainnetとKairos testnetを選択できる。 -## List View +## リスト表示 -If you want to get a closer look at the status of the Kaia network, you can check the list of recently generated blocks and transactions. To access the list page, click the button on the navigation bar which located on the left of the screen. +カイアネットワークの状態を詳しく見たい場合は、最近生成されたブロックとトランザクションのリストを確認することができます。 リストページにアクセスするには、画面左のナビゲーションバーにあるボタンをクリックします。 -### Blocks +### ブロック ![](/img/build/tools/scope_04_block_list.png) -A list of recently generated blocks. To update the information, please click the refresh. +最近生成されたブロックのリスト。 情報を更新するには、更新をクリックしてください。 -- Block: The unique number of the block. Starting from zero \(the genesis block\), it is given sequentially each time a block is generated. -- Time: Duration of time since the block was generated. You can check the exact date and time by hovering this. -- Total TXs: The total number of transactions included in the block. -- Block Proposer: Randomly but deterministically selected Consensus Node that proposed the block. By clicking the address, you can easily go to the details page. -- Reward: Aggregation of newly minted KAIA \(9.6 KAIA\) and transaction fees used in the block. The list displays only the sum of Kaia Governance Council Reward, Proof of Contribution, and Kaia Ecosystem Fund. Hover the block reward section on the block detail page to see detailed information. More details about the block reward distribution system can be found in the [Kaia Token Economy]. -- Size: The size of blocks measured in Byte. The more transactions are included, the larger the block size. +- ブロック：ブロックの固有番号。 ゼロから始まり、ブロックが生成されるたびに順次付与される。 +- 時間：ブロックが生成されてからの時間。 カーソルを合わせれば、正確な日時を確認できる。 +- 総TX数：ブロックに含まれるトランザクションの総数。 +- ブロック提案者：ブロックを提案したコンセンサスノード。 アドレスをクリックすると、簡単に詳細ページに飛ぶことができる。 +- 報酬新たに鋳造された KAIA ㏄（9.6 KAIA ㏄）とブロック内で使用された取引手数料の合算。 リストには、カイア統治評議会報酬、貢献証明、カイア・エコシステム基金の合計のみが表示されます。 ブロックの詳細ページでブロックの報酬セクションにカーソルを合わせると、詳細情報が表示されます。 ブロック報酬分配システムの詳細については、\[カイアトークンエコノミー]をご覧ください。 +- サイズ：Byte単位で表されるブロックのサイズ。 より多くのトランザクションが含まれるほど、ブロックサイズは大きくなる。 -### Transactions +### トランザクション ![](/img/build/tools/scope_05_tx_list.png) -A list of recently executed transactions. To update the information, please click the refresh. +最近実行されたトランザクションのリスト。 情報を更新するには、更新をクリックしてください。 -- TX Hash: The unique identifier of the transaction. For more information, click the hash to go to the detail page. If the transaction fails, a red exclamation mark appears next to it. -- Block \#: Number of the block which contains this transaction. Clicking on the number takes you to the details page of the block. -- Time: Duration of time since the transaction was executed. You can check the exact date and time by hovering this. -- From -> To: The addresses of sender and receiver. By clicking the address, you can easily go to the details page. If the file icon displays next to an address, it means that the address is a contract. -- TX Type: Type of the transaction. You can apply a filter to get the transactions of a specific type. For more information, please visit [Transactions]. -- Amount: The amount of value transferred through the transaction. -- TX Fee: The actual cost used to process transaction. +- TXハッシュ：トランザクションの一意な識別子。 詳しくは、ハッシュをクリックして詳細ページをご覧ください。 トランザクションが失敗すると、その横に赤い感嘆符が表示される。 +- ブロック番号：この取引を含むブロックの番号。 番号をクリックすると、そのブロックの詳細ページに移動します。 +- 時間：トランザクションが実行されてからの時間。 カーソルを合わせれば、正確な日時を確認できる。 +- From -> To：送信者と受信者のアドレス。 アドレスをクリックすると、簡単に詳細ページに飛ぶことができる。 住所の横にファイルアイコンが表示されている場合は、その住所が契約書であることを意味する。 +- TXタイプ：トランザクションのタイプ。 特定のタイプのトランザクションを取得するためにフィルタを適用することができます。 詳しくは[Transactions]をご覧ください。 +- 金額：取引によって移転された価値の量。 +- TX手数料：トランザクション処理に使用される実際のコスト。 -## Detail View +## 詳細表示 -Detailed information about single Block, Transaction, Account, and Contract can be found on this page. To go to the details view, you can search for the entity from the search bar or click the item from the list view. +単一ブロック、取引、口座、契約に関する詳細情報は、このページで確認できます。 詳細ビューに移動するには、検索バーからエンティティを検索するか、リストビューから項目をクリックします。 -### Block +### ブロック ![](/img/build/tools/scope_08_block_detail.png) -#### Overview +#### 概要 -Overall information about the block. +ブロックの全体的な情報。 -- Time: Elapsed time since the block generation. Exact datetime is also displayed next to it. -- Hash: The unique identifier of the block. By pressing the copy button, you can easily copy the hash. -- Parent Hash: The unique identifier of the previous block. Clicking on the hash takes you to the detail view of the parent hash. -- Total TXs: The total number of transactions included in the block. -- More details about block reward distribution system can be found in the [Kaia Token Economy]. If you hover, you will find detailed information on Kaia Governance Council Reward, Proof of Contribution and Kaia Ecosystem Fund. Block Reward: Aggregation of the newly minted KAIA \(9.6 KAIA\) and the transaction fees collected in the block. -- Block Size: The size of block measured in Byte. The more transactions are included, the larger the block size. +- Time: ブロック生成からの経過時間。 正確な日付もその横に表示される。 +- ハッシュ：ブロックの一意な識別子。 コピーボタンを押せば、ハッシュを簡単にコピーできる。 +- 親ハッシュ：前のブロックの一意な識別子。 ハッシュをクリックすると、親ハッシュの詳細ビューに移動します。 +- 総TX数：ブロックに含まれるトランザクションの総数。 +- More details about block reward distribution system can be found in the [Kaia Token Economy]. カーソルを合わせると、カイア・ガバナンス・カウンシルの報酬、貢献の証明、カイア・エコシステム・ファンドに関する詳細情報が表示されます。 Block Reward: Aggregation of the newly minted KAIA \(9.6 KAIA\) and the transaction fees collected in the block. +- ブロックサイズ：ブロックのサイズをByteで表す。 より多くのトランザクションが含まれるほど、ブロックサイズは大きくなる。 -#### Committee +#### 委員会 -List of consensus nodes that proposed and validated the block. +ブロックを提案し、検証したコンセンサスノードのリスト。 -- Block Proposer: Randomly but deterministically selected consensus node that proposed the block. By clicking the address, you can easily go to the detail view of the node. -- Validators: Consensus nodes that validated the block. By clicking the address, you can easily go to the detail view of the node. +- ブロック提案者：ブロックを提案した、ランダムだが決定論的に選択されたコンセンサスノード。 アドレスをクリックすると、そのノードの詳細ビューに簡単に移動できます。 +- バリデータ：ブロックを検証したコンセンサスノード。 アドレスをクリックすると、そのノードの詳細ビューに簡単に移動できます。 -#### Transactions +#### トランザクション -List of transactions included in the block. +ブロックに含まれるトランザクションのリスト。 -### Transaction +### トランザクション ![](/img/build/tools/scope_09_tx_detail.png) -#### Overview +#### 概要 -Overall information about the transaction. +取引に関する全体的な情報。 -- Status indicator: On the upper-right corner. The indicator whether the transaction succeeded or not. -- TX Type: Type of the transaction. For more information, please see [Transactions]. -- Block \#: Number of the block which contains this transaction. Clicking on the number takes you to the detail view of the block. -- From -> To: The addresses of sender and receiver. By clicking the address, you can go to the detail view of the account. If a file icon displays next to the address, it means that address is contract. -- Fee Payer: Displayed when TX type is either Fee Delegated or Fee Delegated with Ratio. When you click the address of fee payer you can go to the detailed view of the account. -- Time: Elapsed time since the transaction was executed. -- Nonce: Number of the transaction sent from the sender's address. Starting from zero, it increases sequentially each time a transaction is sent. -- Amount: The amount of value transferred in this transaction. -- Gas Price: Cost per gas measured in KAIA. In Kaia network, Gas Price is fixed. -- Gas Used: Exact gas that was used to execute the transaction. -- Gas Limit: Maximum gas that the sender was willing to pay for this transaction. -- TX Fee: The actual cost used to process transaction. Calculated by multiplying Gas Price by Gas Used. -- TX Fee by Sender: Displayed when TX type is Fee Delegated with Ratio. The portion of TX fee paid by the sender. -- TX Fee by Fee Payer: Displayed when TX type is Fee Delegated with Ratio. The portion of TX fee paid by the fee payer. +- ステータスインジケータ：右上隅にある。 トランザクションが成功したかどうかの指標。 +- TXタイプ：トランザクションのタイプ。 詳しくは[Transactions]をご覧ください。 +- ブロック番号：この取引を含むブロックの番号。 番号をクリックすると、そのブロックの詳細表示に移動します。 +- From -> To：送信者と受信者のアドレス。 アドレスをクリックすると、アカウントの詳細ビューに移動できます。 アドレスの横にファイルアイコンが表示されている場合は、そのアドレスが契約済みであることを意味する。 +- 料金支払者：TXタイプがFee DelegatedまたはFee Delegated with Ratioの場合に表示される。 料金支払者のアドレスをクリックすると、口座の詳細表示に移動できます。 +- Time: トランザクションが実行されてからの経過時間。 +- Nonce：送信者のアドレスから送信されたトランザクションの番号。 ゼロから始まり、トランザクションが送信されるたびに順次増加する。 +- 金額：金額：このトランザクションで移転された価値の金額。 +- ガス料金：KAIAで測定されたガス単価。 カイヤのネットワークでは、ガス料金は固定されている。 +- 使用ガス：トランザクションの実行に使用された正確なガス。 +- Gas Limit（ガスリミット）：送信者がこの取引に支払う意思のあるガスの上限。 +- TX手数料：トランザクション処理に使用される実際のコスト。 ガス料金÷使用ガス量で算出。 +- 送信者によるTX料金：TXタイプがFee Delegated with Ratioの場合に表示される。 TX料金のうち、送信者が支払う部分。 +- 料金支払者別 TX 料金：TXタイプがFee Delegated with Ratioの場合に表示される。 TX料金のうち、料金支払者が支払う部分。 -#### Input Data +#### 入力データ -Extra data provided by the sender or contract. +送信者または契約者によって提供された追加データ。 -### Account +### アカウント ![](/img/build/tools/scope_10_account_detail.png) -#### Overview +#### 概要 -Overall information about the account. +アカウントに関する全体的な情報。 -- Address \(Hex\): The unique address of the account. -- Balance: The total amount of KAIA that this account has. -- Total TXs: The total number of transactions that this account sent or received. +- Address \(Hex)：アカウントの固有アドレス。 +- 残高：この口座が持っているKAIAの総額。 +- 合計TX数：このアカウントが送受信したトランザクションの総数。 -#### Transactions +#### トランザクション -The list of transactions related to this account. The color of the arrow indicates if the account is a sender or receiver. +この口座に関連する取引のリスト。 矢印の色は、そのアカウントが送信側か受信側かを示す。 -### Contract +### 契約 ![](/img/build/tools/scope_11_contract_detail.png) -#### Overview +#### 概要 -Overall information about the contract. +契約に関する全体的な情報 -- Account \(Hex\): The unique address of the contract. -- Balance: The total amount of KAIA that this contract has. -- Contract Creator: The account that deployed this contract. By clicking the address, you can go to the detail view of the account. -- Total TXs: The total number of transactions that this contract received. -- Contract Created TX: The transaction that deployed this contract. Clicking on the hash takes you to the detail view of the transaction. +- Account \(Hex)：契約の固有アドレス。 +- 残高：この契約が保有するKAIAの総額。 +- 契約作成者：この契約を展開したアカウント。 アドレスをクリックすると、アカウントの詳細ビューに移動できます。 +- 総TX数：この契約が受信したトランザクションの総数。 +- コントラクト作成TX：この契約を展開したトランザクション。 ハッシュをクリックすると、トランザクションの詳細ビューが表示されます。 -#### Transactions +#### トランザクション -The list of transactions related to this contract. +この契約に関連する取引のリスト。 -## Search +## 検索 -Through Kaiascope, you can search for the information about account, contract, transactions and blocks. The search bar is placed on every page, making it easy to access. Entering a valid keyword will take you to the detail view of the entity. +Kaiascopeを通じて、口座、契約、取引、ブロックに関する情報を検索することができます。 検索バーはすべてのページに設置されており、簡単にアクセスできる。 有効なキーワードを入力すると、そのエンティティの詳細ビューに移動します。 ![](/img/build/tools/scope_06_search.png) -### Search Keyword +### 検索キーワード -In the mainnet version, searchable keywords are as follows: +メインネット版では、検索可能なキーワードは以下の通り： -- Block \# -- TX Hash -- Address \(Account, Contract\) +- ブロック +- TXハッシュ +- Address -### Keyword Format +### キーワード形式 -The unique characteristics that distinguish each keyword are as follows: +各キーワードの特徴は以下の通り： -#### Block +#### ブロック -- Decimal numbers only \[0~9\] +- 10進数のみ ୧[0～9］ -#### TX Hash +#### TXハッシュ -- 66 characters long -- Starts with a prefix `0x` -- Hexadecimal number only \[0~9, a~f\] +- 66文字 +- 接頭辞 `0x` で始まる。 +- 16進数のみ ୧[0～9, a～f］ -#### Address +#### 住所 -- 42 characters long -- Start with a prefix `0x` -- Hexadecimal number only \[0~9, a~f\] +- 42文字 +- 接頭辞 `0x` から始める +- 16進数のみ ୧[0～9, a～f］ -### Search Errors +### 検索エラー ![](/img/build/tools/scope_07_noresult.png) If you search for a keyword that doesn't fit in the specified format or information hasn't yet been generated, no result page will appear. -#### Wrong Format \(TX Hash / Address\) +#### フォーマットが間違っています。 -- Wrong number of characters -- Doesn't start with a prefix `0x` -- Contains special characters or non-hexadecimal characters \[g~z\] +- 文字数の間違い +- 接頭辞 `0x` で始まらない。 +- 特殊文字または16進数以外の文字が含まれている。 -#### Doesn't Exist +#### 存在しない -- Blocks not yet generated \(if the block number entered was higher than recently generated block number\) -- Non-existent TX Hash +- 未発生ブロック(入力したブロック番号が最近発生したブロック番号より大きい場合) +- 存在しないTXハッシュ [Transactions]: ../../../learn/transactions/transactions.md [Kaia Token Economy]: ../../../learn/token-economy.md diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md index 47bdea7fbea0..90e1417fe389 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md @@ -1,24 +1,24 @@ -# Cross-Chain Interoperability +# クロスチェーン相互運用性 -Cross-chain interoperability protocols are designed to connect blockchain networks that were originally isolated and independent. These protocols enable different chains to interact, allowing for the movement of liquidity and state between them. By establishing rules and processes for transferring assets and data across different blockchain networks, cross-chain interoperability protocols facilitate seamless collaboration and exchange of information between otherwise separate systems. +クロスチェーン相互運用性プロトコルは、もともと孤立し独立していたブロックチェーン・ネットワークを接続するために設計されている。 これらのプロトコルは、異なるチェーンの相互作用を可能にし、チェーン間の流動性と状態の移動を可能にする。 異なるブロックチェーン・ネットワーク間で資産やデータを転送するためのルールやプロセスを確立することで、クロスチェーンの相互運用性プロトコルは、別個のシステム間のシームレスな連携や情報交換を促進する。 -## Broad Scope of Cross-Chain Solutions +## クロスチェーン・ソリューションの幅広い範囲 -Cross-chain interoperability is a comprehensive concept encompassing various technologies: +クロスチェーンの相互運用性は、さまざまな技術を包含する包括的な概念である： -1. **Cross-Chain Messaging Protocols**: These enable broad interoperability, supporting diverse operations such as data exchange and cross-chain smart contract execution. +1. **クロスチェーン・メッセージング・プロトコル**：これらは幅広い相互運用性を可能にし、データ交換やクロスチェーン・スマートコントラクトの実行といった多様なオペレーションをサポートする。 -2. **Cross-Chain Bridges**: A specific subset of cross-chain solutions, bridges focus primarily on asset transfer between chains. They play a crucial role in connecting assets across the different blockchain ecosystems but have a more specialized function compared to general messaging protocols. +2. **クロスチェーン・ブリッジ**：クロスチェーン・ソリューションの特定のサブセットであるブリッジは、主にチェーン間の資産移転に焦点を当てている。 異なるブロックチェーンエコシステム間のアセット接続において重要な役割を果たすが、一般的なメッセージングプロトコルに比べてより専門的な機能を持つ。 -## Kaia's Compatibility +## カイアの相性 -Kaia network is currently compatibile with leading cross-chain solutions, enhancing its connectivity within the broader blockchain landscape. The following are currently supported on Kaia: +カイア・ネットワークは現在、主要なクロスチェーン・ソリューションと互換性があり、より広範なブロックチェーンランドスケープにおける接続性を高めている。 現在カイアでサポートされているのは以下の通り： -### Cross-Chain Messaging Protocols: +### クロスチェーン・メッセージング・プロトコル -- [LayerZero](https://layerzero.network/) -- [Wormhole](https://wormhole.com/) +- [レイヤーゼロ](https://layerzero.network/) +- [ワームホール](https://wormhole.com/) -### Cross-Chain Bridges: +### クロスチェーン・ブリッジ -- [Stargate](https://stargate.finance/) +- [スターゲイト](https://stargate.finance/) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md index eb55dbd760c7..9054c684507e 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md @@ -1,13 +1,13 @@ # Layerzero -## Introduction +## はじめに -[LayerZero](https://docs.layerzero.network/v2) as an omnichain interoperability protocol in Web3 enables applications to move data across blockchains, uniquely supporting censorship-resistant messages and permissionless development through immutable smart contracts. Layerzero provides a rich suite of tools for developing omnichain applications, hence developers can easily [send arbitrary data](https://docs.layerzero.network/v2/home/protocol/contract-standards#oapp), [external function calls](https://docs.layerzero.network/v2/developers/evm/oapp/message-design-patterns), and [tokens](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft) while preserving full autonomy and control over their application. +Web3におけるオムニチェーン相互運用性プロトコルとしての[LayerZero](https://docs.layerzero.network/v2)は、アプリケーションがブロックチェーン間でデータを移動することを可能にし、検閲に耐性のあるメッセージと、不変のスマートコントラクトによるパーミッションレス開発を独自にサポートする。 Layerzeroは、オムニチェーン・アプリケーションを開発するための豊富なツール群を提供します。そのため、開発者は、アプリケーションの完全な自律性と制御を維持しながら、簡単に[任意のデータを送信](https://docs.layerzero.network/v2/home/protocol/contract-standards#oapp)、[外部関数呼び出し](https://docs.layerzero.network/v2/developers/evm/oapp/message-design-patterns)、[トークン](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft)することができます。 -## Usage +## 使用方法 -Layerzero supports both [Kaia Mainnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#klaytn) and [Kairos Testnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#klaytn-baobab). To get started using LayerZero on Kaia, refer to the following guides: +Layerzeroは[Kaia Mainnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#klaytn)と[Kairos Testnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#klaytn-baobab)の両方をサポートしています。 カイアでLayerZeroを使い始めるには、以下のガイドを参照してください： - [LayerZero V2 OApp Quickstart](https://docs.layerzero.network/v2/developers/evm/oapp/overview) -- [LayerZero V2 OFT Quickstart](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) -- [LayerZero V2 ONFT Quickstart](https://docs.layerzero.network/v2/developers/evm/onft/quickstart) +- [LayerZero V2 OFT クイックスタート](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) +- [LayerZero V2 ONFT クイックスタート](https://docs.layerzero.network/v2/developers/evm/onft/quickstart) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md index 5c8c421169b8..6728276bc73c 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md @@ -1,11 +1,11 @@ # Stargate -## Introduction +## はじめに -[Stargate](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs) is the first fully composable native asset bridge, and the first dApp built on LayerZero. The core of Stargate is to make cross-chain liquidity transfer a seamless, single transaction process. With Stargate, users can swap native assets cross-chain within a single transaction. Meaning that you can swap ETH for KAIA in a single transaction. +[Stargate](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs)は、初の完全コンポーザブル・ネイティブ・アセット・ブリッジであり、LayerZero上に構築された初のdAppである。 スターゲートの核心は、クロスチェーンの流動性移転をシームレスな単一取引プロセスにすることである。 スターゲイトでは、ユーザーは単一のトランザクション内でネイティブ資産をクロスチェーンで交換することができます。 つまり、1回の取引でETHとKAIAを交換できる。 -## Usage +## 使用方法 -Stargate provides a way for developers to perform swaps programmatically in their apps. You can perform swaps programmatically both on [Kaia Mainnet](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/technical-reference/mainnet-contracts#klaytn) and [Kairos Testnet](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/technical-reference/testnet-contracts#klaytn-baobab-testnet). To get started, refer to the following guides: +Stargateは、開発者が自分のアプリでプログラム的にスワップを実行する方法を提供します。 Kaiaメインネット](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/technical-reference/mainnet-contracts#klaytn)と[Kairosテストネット](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/technical-reference/testnet-contracts#klaytn-baobab-testnet)の両方で、プログラム的にスワップを実行することができます。 まずは、以下のガイドをご参照ください： -- [How to swap](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/integrate-with-stargate/how-to-swap) +- [スワップ方法](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/integrate-with-stargate/how-to-swap) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md index fbabb595efc5..67bd6369846a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md @@ -1,13 +1,13 @@ # Wormhole -## Introduction +## はじめに -[Wormhole](https://wormhole.com/docs/) is an interoperability platform powering multi chain apps and bridges. It currently has support for 30+ chains including Kaia. By integrating wormhole, a Kaia application can make any token natively multichain, pull any on-chain data on-demand and build custom multi chain protocols. +[Wormhole](https://wormhole.com/docs/)は、マルチチェーンアプリとブリッジを支える相互運用性プラットフォームである。 現在、カイアを含む30以上のチェーンに対応している。 ワームホールを統合することで、カイアのアプリケーションはあらゆるトークンをネイティブにマルチチェーン化し、オンデマンドであらゆるオンチェーンデータを引き出し、カスタムマルチチェーンプロトコルを構築することができる。 -## Usage +## 使用方法 -Wormhole supports both [Kaia Mainnet](https://wormhole.com/docs/build/start-building/supported-networks/evm/#__tabbed_34_1) and [Kairos Testnet](https://wormhole.com/docs/build/start-building/supported-networks/evm/#__tabbed_35_1). To get started using Wormhole on Kaia, refer to the following guides: +Wormholeは[Kaia Mainnet](https://wormhole.com/docs/build/start-building/supported-networks/evm/#__tabbed_34_1)と[Kairos Testnet](https://wormhole.com/docs/build/start-building/supported-networks/evm/#__tabbed_35_1)の両方をサポートしています。 カイアでワームホールを使い始めるには、以下のガイドを参照してください： -- [Create Cross-Chain Messaging Contract](https://wormhole.com/docs/tutorials/messaging/cross-chain-contracts/) -- [Create Cross-Chain Token Transfers](https://wormhole.com/docs/tutorials/messaging/cross-chain-token-contracts/) +- [クロスチェーン・メッセージング契約の締結](https://wormhole.com/docs/tutorials/messaging/cross-chain-contracts/) +- [クロスチェーントークン転送の作成](https://wormhole.com/docs/tutorials/messaging/cross-chain-token-contracts/) - [Github Examples](https://github.com/wormhole-foundation/wormhole-examples) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md index 053d5537c493..8bab9ec12edf 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md @@ -1,8 +1,8 @@ # Indexers -Blockchain indexers are tools used in the context of blockchain technology to improve the efficiency and speed of searching, querying, and accessing data stored on a blockchain. They create and maintain organized databases of the blockchain's data, allowing users to quickly retrieve information without needing to process the entire blockchain from scratch. +ブロックチェーンインデクサーは、ブロックチェーン技術の文脈で使用されるツールで、ブロックチェーン上に保存されたデータの検索、クエリ、アクセスの効率と速度を向上させる。 ブロックチェーンのデータを整理したデータベースを作成・管理することで、ユーザーはブロックチェーン全体をゼロから処理することなく、素早く情報を取り出すことができる。 -The following providers have integrated with Klaytn to deliver blockchain indexing services: +以下のプロバイダーがKaiaと統合し、ブロックチェーンインデキシングサービスを提供しています： -- [The Graph](https://thegraph.com/) +- [グラフ](https://thegraph.com/) - [SubQuery Network](https://academy.subquery.network/) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md index 201ae765e388..2923caa1c9de 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md @@ -2,37 +2,37 @@ sidebar_label: SubQuery --- -# SubQuery Multi-Chain Indexer +# サブクエリー・マルチチェーン・インデクサー -SubQuery is a leading blockchain data indexer that provides developers with fast, flexible, universal, open source and decentralized APIs for web3 projects. The SubQuery SDK allows developers to get rich indexed data and build intuitive and immersive decentralized applications in a faster and more efficient way. SubQuery supports 100+ ecosystems including Klaytn's EVM, Cosmos, Ethereum, Polygon, Polkadot, Algorand, NEAR, and Avalanche. +SubQueryはブロックチェーンデータインデクサーのリーディングカンパニーであり、開発者にWeb3プロジェクト用の高速で柔軟、普遍的、オープンソース、分散型APIを提供します。 SubQuery SDKにより、開発者はリッチなインデックス付きデータを取得し、直感的で没入感のある分散型アプリケーションをより迅速かつ効率的に構築することができる。 SubQueryは、KaiaのEVM、Cosmos、Ethereum、Polygon、Polkadot、Algorand、NEAR、Avalancheを含む100以上のエコシステムをサポートしています。 -Another one of SubQuery's competitive advantages is the ability to aggregate data not only within a chain but across multiple blockchains all within a single project. This allows the creation of feature-rich dashboard analytics or multi-chain block scanners. +SubQueryのもう1つの競争上の優位性は、チェーン内だけでなく、1つのプロジェクト内で複数のブロックチェーンにまたがるデータを集約できることだ。 これにより、機能豊富なダッシュボード分析やマルチチェーン・ブロックスキャナーの作成が可能になる。 -Other advantages include superior performance with multiple RPC endpoint configurations, multi-worker capabilities and a configurable caching architecture. To find out more, visit our [documentation](https://academy.subquery.network/). +その他の利点としては、複数のRPCエンドポイント構成による優れたパフォーマンス、マルチワーカー機能、設定可能なキャッシュ・アーキテクチャなどがある。 詳しくは[ドキュメント](https://academy.subquery.network/)をご覧ください。 -## Getting started +## スタート -Take a look at this [SubQuery Starter Project](https://github.com/subquery/ethereum-subql-starter/tree/main/Klaytn/klaytn-starter) that introduces SubQuery's Klaytn support by indexing all transfers and approval events from the Orbit ETH on Klaytn Network . +この[SubQuery Starter Project](https://github.com/subquery/ethereum-subql-starter/tree/main/Kaia/klaytn-starter)を見て、Kaia Network上のOrbit ETHからのすべての送金と承認イベントのインデックスを作成することで、SubQueryのKaiaサポートを紹介しましょう。 -You can also follow along this [step by step guide](https://academy.subquery.network/quickstart/quickstart.html) to get familiar with SubQuery or check out the [Klaytn x SubQuery workshop](https://www.youtube.com/watch?v=40R5O1kL3v4) to see an actual demo. +また、この[ステップバイステップガイド](https://academy.subquery.network/quickstart/quickstart.html)に沿ってSubQueryに慣れることもできますし、[Kaia x SubQueryワークショップ](https://www.youtube.com/watch?v=40R5O1kL3v4)で実際のデモを見ることもできます。 -## Running and Hosting your Klaytn SubQuery APIs +## KaiaサブクエリーAPIの実行とホスティング -SubQuery is open-source, meaning you have the freedom to run it in the following three ways: +SubQueryはオープンソースであるため、以下の3つの方法で自由に実行することができる： -- Locally on your own computer, or a cloud provider of your choosing. View the instructions on how to run SubQuery locally [here](https://academy.subquery.network/run_publish/run.html). +- ご自身のコンピューターにローカルに、またはお好みのクラウドプロバイダーに。 SubQueryをローカルで実行する方法については、[こちら](https://academy.subquery.network/run_publish/run.html)を参照してください。 -You can publish it to SubQuery's enterprise-level [Managed Service](https://managedservice.subquery.network/login), where we'll host your SubQuery project in production ready services for mission critical data with zero-downtime blue/green deployments. There even is a generous free tier. [Find out how](https://academy.subquery.network/run_publish/publish.html). +SubQueryのエンタープライズレベルの[マネージドサービス](https://managedservice.subquery.network/login)に公開することができます。SubQueryプロジェクトは、ダウンタイムなしのブルー/グリーンデプロイメントで、ミッションクリティカルなデータのためのプロダクションレディのサービスでホストされます。 寛大な無料ティアもある。 [その方法を探る](https://academy.subquery.network/run_publish/publish.html)。 -You can publish it to the decentralized SubQuery Network, the most open, performant, reliable, and scalable data service for dApp developers. The SubQuery Network indexes and services data to the global community in an incentivised and verifiable way and supports Klaytn from launch. +dApp開発者のための最もオープンでパフォーマンス、信頼性、スケーラブルなデータサービスである分散型SubQuery Networkに公開することができます。 SubQuery Networkは、インセンティブと検証可能な方法で、グローバルコミュニティにインデックスを作成し、データを提供し、立ち上げからKaiaをサポートする。 -## Resources +## リソース -Here are some additional resources to help you get started with SubQuery: +SubQueryを使い始めるのに役立つ追加リソースをいくつかご紹介します： -- [SubQuery Website](https://subquery.network/?utm_source=klaytn\\\\&utm_medium=partner-docs) -- [Documentation](https://academy.subquery.network/?utm_source=klaytn\\\\&utm_medium=partner-docs) -- [SubQuery Klaytn Support Announcement](https://subquery.medium.com/subquerys-data-indexing-supports-builders-on-klaytn-e5a3aec4bc14?utm_source=klaytn\\\\&utm_medium=partner-docs) -- [Klaytn Quick Start](https://academy.subquery.network/quickstart/quickstart_chains/klaytn.html/?utm_source=klaytn\\\\&utm_medium=partner-docs) -- [Klaytn Starter Project](https://github.com/subquery/ethereum-subql-starter/tree/main/Klaytn/klaytn-starter) -- [Discord Support](https://discord.com/invite/subquery/?utm_source=klaytn\\\\&utm_medium=partner-docs) +- [SubQueryウェブサイト](https://subquery.network/?utm_source=klaytn\\\\\&utm_medium=partner-docs) +- [ドキュメント](https://academy.subquery.network/?utm_source=klaytn\&utm_medium=partner-docs) +- [SubQuery Kaia サポート 発表](https://subquery.medium.com/subquerys-data-indexing-supports-builders-on-klaytn-e5a3aec4bc14?utm_source=klaytn\\\\\&utm_medium=partner-docs) +- [カイア・クイックスタート](https://academy.subquery.network/quickstart/quickstart_chains/klaytn.html/?utm_source=klaytn\&utm_medium=partner-docs) +- [カイヤスタータープロジェクト](https://github.com/subquery/ethereum-subql-starter/tree/main/Kaia/klaytn-starter) +- [ディスコードサポート](https://discord.com/invite/subquery/?utm_source=klaytn\&utm_medium=partner-docs) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md index 5492a45d2fc5..01f408140679 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md @@ -4,167 +4,167 @@ sidebar_label: The Graph # The Graph -Getting historical data on a smart contract can be frustrating when building a dapp. [The Graph](https://thegraph.com/) provides an easy way to query smart contract data through APIs known as subgraphs. The Graph’s infrastructure relies on a decentralized network of indexers, enabling your dapp to become truly decentralized. +スマートコントラクトの履歴データを取得することは、ダップ構築時にフラストレーションがたまることがある。 [The Graph](https://thegraph.com/)は、サブグラフと呼ばれるAPIを通じてスマートコントラクトのデータを照会する簡単な方法を提供する。 Graphのインフラはインデクサーの分散型ネットワークに依存しており、あなたのダップが真の分散型になることを可能にする。 -Both Kaia Mainnet & Testnet are supported by The Graph. +カイア・メインネットとテストネットはどちらもザ・グラフのサポートを受けている。 -## Quick Start +## クイックスタート -These subgraphs only take a few minutes to set up. To get started, follow these three steps: +これらのサブグラフの設定には数分しかかからない。 始めるには、以下の3つのステップを踏む： -1. Initialize your subgraph project -2. Deploy & Publish -3. Query from your dapp +1. サブグラフ・プロジェクトを初期化する +2. デプロイとパブリッシュ +3. ダップからのクエリー -Pricing: +価格設定： -- The rate-limited test endpoints in Studio are free. -- API calls for the decentralized network are pay-per-use at $4 per 100K queries. The first 100K queries are free! +- Studioのレート制限付きテストエンドポイントは無料。 +- 分散型ネットワークのAPIコールは有料で、10万クエリーあたり4ドル。 最初の10万クエリーは無料！ -Here’s a step by step walk through: +以下、順を追って説明しよう： -## 1. Initialize your subgraph project +## 1. サブグラフ・プロジェクトを初期化する -### Create a subgraph on Subgraph Studio⁠ +### Subgraph Studioでサブグラフを作成する -Go to the [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet. Once your wallet is connected, you can begin by clicking “Create a Subgraph”. When choosing a name, it is recommended to use Title Case: “Subgraph Name Chain Name.” +Subgraph Studio](https://thegraph.com/studio/)にアクセスし、ウォレットを接続する。 ウォレットが接続されたら、"Create a Subgraph "をクリックします。 名称を決める際には、タイトル・ケースを使うことを推奨する。 ![Create a Subgraph](/img/build/tools/graph/01-create-subgraph.png) -You will then land on your subgraph’s page. All the CLI commands you need will be visible on the right side of the page: +サブグラフのページが表示されます。 必要なCLIコマンドはすべてページの右側に表示されます： ![CLI commands](/img/build/tools/graph/02-cli-commands.webp) -### Install the Graph CLI⁠ +### Graph CLIのインストール -On your local machine run the following: +ローカル・マシンで以下を実行する： ``` npm install -g @graphprotocol/graph-cli ``` -### Initialize your Subgraph⁠ +### サブグラフを初期化する -You can copy this directly from your subgraph page to include your specific subgraph slug: +これをサブグラフのページから直接コピーして、特定のサブグラフのスラッグを含めることができる： ``` -graph init --studio +グラフ開始 --スタジオ ``` -You’ll be prompted to provide some info on your subgraph like this: +このように、サブグラフに関する情報を入力するプロンプトが表示される： ![CLI sample](/img/build/tools/graph/03-cli-sample.webp) -After entering the contract info, the graph-cli will attempt to fetch ABI, StartBLock & Contract name from the blockexplorer API. +コントラクト情報を入力すると、graph-cli は blockexplorer API から ABI、StartBLock、コントラクト名を取得しようとします。 -However, KaiaScan's API is not ready yet, so when asked to retry, just say "no". Here's how to obtain these manually: +ただし、KaiaScanのAPIはまだ準備ができていないので、再試行を求められたら「いいえ」と答えてください。 手動で入手する方法は以下の通り： -1. ABI: You need to prepare a json file containing the ABI in the same directory where you're running `graph init`. From the [contract's page on Kaiascan](https://kaiascan.io/address/0x5096db80b21ef45230c9e423c373f1fc9c0198dd), go to the `Contract` tab, click `View Code` and you'll be able to copy the ABI. Save it as a json file in the same folder where you're running `graph init`. In this screenshot above, it was saved as `abi.json`. +1. ABI: ABIを含むjsonファイルを`graph init`を実行しているディレクトリに用意する必要がある。 [Kaiascanの契約のページ](https://kaiascan.io/address/0x5096db80b21ef45230c9e423c373f1fc9c0198dd)から、`Contract`タブを開き、`View Code`をクリックすると、ABIをコピーすることができます。 それをjsonファイルとして、`graph init`を実行しているフォルダと同じ場所に保存する。 上のスクリーンショットでは、`abi.json`として保存されている。 ![Finding ABI](/img/build/tools/graph/04-kaiascan-abi.webp) -2. Start Block: Click into the transaction hash where the contract was created. There you'll find the block where the contract was created. +2. ブロックを開始する：契約が作成されたトランザクションハッシュをクリックします。 そこに契約が作成されたブロックがある。 ![contract creation](/img/build/tools/graph/05-contract-creation.webp) -3. Contract Name: Just type in the name of the contract. If this is the only contract you're indexing in this subgraph, it's OK to just go with the default `Contract`. +3. 契約名：契約名を入力してください。 このサブグラフでインデックスを作成するコントラクトがこれだけであれば、デフォルトの `Contract` を使用しても問題ありません。 ## 3) Query your Subgraph -### Deploy to Subgraph Studio⁠ +### Subgraph Studioにデプロイする -First run these commands: +まず、以下のコマンドを実行する： ```bash $ graph codegen $ graph build ``` -Then run these to authenticate and deploy your subgraph. You can copy these commands directly from your subgraph’s page in Studio to include your specific deploy key and subgraph slug: +次に、これらを実行してサブグラフを認証し、デプロイする。 これらのコマンドをStudioのサブグラフのページから直接コピーして、特定の配置キーとサブグラフのスラッグを含めることができます： ```bash -$ graph auth --studio -$ graph deploy --studio +$ graph auth --studio +$ graph deploy --studio ``` -You will be asked for a version label. You can enter something like v0.0.1, but you’re free to choose the format. +バージョンラベルの入力を求められます。 v0.0.1のように入力できますが、形式は自由に選んでください。 -### Test your subgraph⁠ +### サブグラフをテストする -You can test your subgraph by making a sample query in the playground section. The Details tab will show you an API endpoint. You can use that endpoint to test from your dapp. +プレイグラウンド・セクションでサンプル・クエリーを作成し、サブグラフをテストすることができる。 DetailsタブにはAPIエンドポイントが表示されます。 そのエンドポイントを使って、ダップからテストすることができる。 ![Playground](/img/build/tools/graph/06-playground.png) -### Publish Your Subgraph to The Graph’s Decentralized Network +### グラフの分散型ネットワークにサブグラフを公開する -Once your subgraph is ready to be put into production, you can publish it to the decentralized network. On your subgraph’s page in Subgraph Studio, click on the Publish button: +サブグラフが完成したら、分散ネットワークに公開することができる。 Subgraph Studioのサブグラフのページで、Publishボタンをクリックします： ![publish button](/img/build/tools/graph/07-studio-publish-subgraph.webp) -> **Note:** +> **注** > -> - Kaia shows as "partially supported" for now because a final on-chain voting process to unlock rewards for indexers has not been completed yet. For now, Edge & Node's Indexer (Upgrade Indexer) will be the only indexer supporting all Kaia subgraphs. -> - The Graph's smart contracts are all on Arbitrum One, even though your subgraph is indexing data from Kaia, Ethereum or any other [supported chain](https://thegraph.com/docs/en/developing/supported-networks/). +> - インデクサーの報酬をアンロックするための最終的なオンチェーン投票プロセスがまだ完了していないため、カイアは今のところ「部分的にサポートされている」と表示されている。 今のところ、Edge & Nodeのインデクサー（アップグレード・インデクサー）が、すべてのカイア・サブグラフをサポートする唯一のインデクサーとなる。 +> - グラフのスマートコントラクトはすべてArbitrum One上にあり、サブグラフがKaiaやEthereum、その他の[サポートされているチェーン](https://thegraph.com/docs/en/developing/supported-networks/)のデータをインデックスしていても、そのデータはArbitrum One上にある。 -## 3. Query your Subgraph +## 3. 3. Query your Subgraph -Congratulations! You can now query your subgraph on the decentralized network! +おめでとう！ これで分散型ネットワーク上で自分のサブグラフを照会できる！ -For any subgraph on the decentralized network, you can start querying it by passing a GraphQL query into the subgraph’s query URL which can be found at the top of its Explorer page. +分散ネットワーク上のどのサブグラフに対しても、エクスプローラーページの一番上にあるサブグラフのクエリーURLにGraphQLクエリーを渡すことでクエリーを開始できる。 -Here’s an example from the [CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari: +これはMessariによる[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK)からの例である： ![Query URL](/img/build/tools/graph/08-query-url.png) -The query URL for this subgraph is: +このサブグラフのクエリーURLは以下の通り： `https://gateway-arbitrum.network.thegraph.com/api/`**[api-key]**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK` -Now, you simply need to  fill in your own API Key to start sending GraphQL queries to this endpoint. +このエンドポイントにGraphQLクエリーを送信するためには、API Keyを入力する必要がある。 -### Getting your own API Key +### APIキーの取得 ![API keys](/img/build/tools/graph/09-apikeys.png) -In Subgraph Studio, you’ll see the “API Keys” menu at the top of the page. Here you can create API Keys. +Subgraph Studioでは、ページ上部に "API Keys "メニューが表示されます。 ここでAPIキーを作成することができます。 -## Appendix +## 付録 -### Sample Query +### サンプルクエリー -This query shows the most expensive CryptoPunks sold. +このクエリでは、最も高価なCryptoPunksが販売されている。 ```graphql { trades(orderBy: priceETH, orderDirection: desc) { priceETH tokenId - } + }. } ``` -Passing this into the query URL returns this result: +これをクエリーURLに渡すと、このような結果が返される： ``` { - "data": { - "trades": [ + "data"：{ + "trades"：[ { - "priceETH": "124457.067524886018255505", - "tokenId": "9998" + "priceETH"："124457.067524886018255505", + "tokenId"："9998" }, { - "priceETH": "8000", - "tokenId": "5822" + "priceETH"："8000", + "tokenId"："5822" }, -// ... +// ... ``` -### Sample code +### サンプルコード ```jsx const axios = require('axios'); @@ -199,7 +199,7 @@ axios(graphQLRequest) }); ``` -### Additional resources: +### その他のリソース -- To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](https://thegraph.com/docs/en/developing/creating-a-subgraph/). -- For more information about querying data from your subgraph, read more [here](https://thegraph.com/docs/en/querying/querying-the-graph/). +- より良いパフォーマンスのためにサブグラフを最適化＆カスタマイズする方法については、[サブグラフの作成](https://thegraph.com/docs/en/developing/creating-a-subgraph/)をお読みください。 +- サブグラフからのデータ・クエリについては、[こちら](https://thegraph.com/docs/en/querying/querying-the-graph/)を参照してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md index 3c2529911098..71d777fdf1f5 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md @@ -2,84 +2,84 @@ ![](/img/banners/kaia-kcw.png) -## Introduction +## はじめに -Kaia prioritizes providing a seamless developer experience, which is the driving force behind the creation of the Kaia Contracts Wizard (KCW). It's worth noting that the Kaia contracts wizard is built on the foundation of the OpenZeppelin Wizard, further bolstering the security of smart contract development. KCW serves as an interactive tool for effortlessly bootstrapping your smart contracts and utilizing the secure, tested components available in [Kaia Contracts](https://github.com/kaiachain/kaia-contracts). In essence, it simplifies the process of developing smart contracts by leveraging the components of Kaia contracts. +カイアは、シームレスな開発者体験を提供することを優先しており、これがカイア・コントラクト・ウィザード（KCW）創設の原動力となっています。 In essence, it simplifies the process of developing smart contracts by leveraging the components of Kaia contracts. It's worth noting that the Kaia contracts wizard is built on the foundation of the OpenZeppelin Wizard, further bolstering the security of smart contract development. KCW serves as an interactive tool for effortlessly bootstrapping your smart contracts and utilizing the secure, tested components available in [Kaia Contracts](https://github.com/kaiachain/kaia-contracts). -In this guide you will: +このガイドでは、次のことを学ぶ： -- Understand the basic functionality of Kaia Contracts Wizard. -- Generate and customize smart contract code using Kaia Contracts Wizard. -- Deploy Kaia contracts to the Kaia Network (Kairos) using Foundry Scripting System. +- カイヤ契約ウィザードの基本機能を理解する。 +- Kaiaコントラクトウィザードを使用してスマートコントラクトコードを生成し、カスタマイズします。 +- Foundry Scripting Systemを使用して、KaiaコントラクトをKaia Network (Kairos)にデプロイする。 -## Exploring Kaia Contracts Wizard +## カイアの契約ウィザードを探る -Kaia Contracts Wizard posits itself as the fastest and easiest way to write your smart contract using Kaia Contracts. In this section, we will dive into the various components and segments of the Kaia Contract Wizard. +Kaiaコントラクトウィザードは、Kaiaコントラクトを使用してスマートコントラクトを記述する最も速く簡単な方法です。 このセクションでは、カイア・コントラクト・ウィザードの様々なコンポーネントとセグメントについて説明します。 -As it is, the Kaia contracts wizard supports the following token standards: +現状では、カイアのコントラクトウィザードは以下のトークン標準をサポートしています： -- [KIP-7](https://kips.kaia.io/KIPs/kip-7) — This is a fungible token standard for Kaia. Fungible means that all tokens are divisible and interchangeable, that is, have the same value. One typical example of fungible tokens is fiat currencies, where each equal-denomination bill has the same value. -- [KIP-17](https://kips.kaia.io/KIPs/kip-17) — This is a non-fungible token standard for Kaia. Non-fungible means that each token is indivisible, and therefore, unique. A KIP17 token can represent ownership of a unique item, whether physical property or virtual collectibles — like a picture, item in a game, real estate, and so on. -- [KIP-37](https://kips.kaia.io/KIPs/kip-37) — This is known as the multi-token standard for Kaia, because it can represent both fungible and non-fungible tokens in a single smart contract. +- [KIP-7](https://kips.kaia.io/KIPs/kip-7) - カイアのカンジブルトークン規格。 Fungibleとは、すべてのトークンが分割可能で交換可能、つまり同じ価値を持つことを意味する。 カジタブル・トークンの典型的な例のひとつが不換紙幣で、同額紙幣はそれぞれ同じ価値を持つ。 +- [KIP-17](https://kips.kaia.io/KIPs/kip-17) - これはカイアの非腐敗性トークン規格である。 菌類でないとは、各トークンが分割不可能であり、したがって一意であることを意味する。 KIP17トークンは、写真、ゲーム内のアイテム、不動産など、物理的な所有物であれ、仮想的な収集物であれ、ユニークなアイテムの所有権を表すことができる。 +- [KIP-37](https://kips.kaia.io/KIPs/kip-37) - これはKaiaのマルチ・トークン標準として知られている。なぜなら、1つのスマート・コントラクトでカビるトークンとカビないトークンの両方を表現できるからだ。 -In line with our [Ethereum Equivalence](https://medium.com/klaytn/toward-ethereum-equivalence-1-introducing-klaytn-v1-8-0-971911be7ff9) support, Kaia contracts wizard also supports [ERC20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/), [ERC721](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/), [ERC1155](https://ethereum.org/en/developers/docs/standards/tokens/erc-1155/). +[Ethereum Equivalence](https://medium.com/klaytn/toward-ethereum-equivalence-1-introducing-klaytn-v1-8-0-971911be7ff9)のサポートに伴い、Kaiaコントラクトウィザードは[ERC20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/)、[ERC721](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/)、[ERC1155](https://ethereum.org/en/developers/docs/standards/tokens/erc-1155/)もサポートしています。 -Kaia Contracts Wizard is comprised of the following sections: +カイア契約ウィザードは以下のセクションで構成されています： -- **Token standard section**: This tab comprises all the different token standards supported by the Kaia contracts wizard. +- **トークン標準セクション**：このタブは、カイアのコントラクトウィザードでサポートされているすべての異なるトークン標準から構成されています。 -- **Settings section**: This section provides the preliminary settings for each token standard, such as token name, symbol, pre-mint (token supply when the contract is deployed), and URI (for non-fungible tokens). +- **設定セクション**：このセクションでは、トークン名、シンボル、プレミント（コントラクトがデプロイされたときにトークンが供給される）、URI（腐敗しないトークンの場合）など、各トークン標準の事前設定を提供します。 -- **Features section**: comprises all features available for each token standard. You can find more information about the different extensions available for each tokens in the following links: +- **特徴セクション**：各トークン規格で利用可能なすべての特徴から構成されています。 各トークンで利用可能なさまざまなエクステンションの詳細については、以下のリンクを参照してください： - [KIP7](https://github.com/kaiachain/kaia-contracts/tree/master/contracts/KIP/token/KIP7/extensions) - [KIP17](https://github.com/kaiachain/kaia-contracts/tree/master/contracts/KIP/token/KIP17/extensions) - [KIP37](https://github.com/kaiachain/kaia-contracts/tree/master/contracts/KIP/token/KIP37/extensions) -- **Access Control section**: comprises all the available access control mechanisms for each token standard. +- **アクセス制御セクション**：各トークン規格で利用可能なすべてのアクセス制御メカニズムから構成される。 -- **Interactive code display section**: this displays the smart contract code generated with the configuration as set by the user. +- **インタラクティブ・コード表示セクション**：ユーザーが設定したコンフィギュレーションで生成されたスマート・コントラクト・コードが表示されます。 ![](/img/build/tools/kcw-image.png) -Having explored the different parts of the Kaia contracts wizard, you can now select the kind of contract that you want (current support for **KIP7**, **KIP17**, **KIP37**, **ERC20**, **ERC721**, **ERC1155**, **Governor**, and custom contracts), set your parameters and desired features (token name, symbol, pre-mint amount, access control, etc.), and Contracts Wizard will generate all of the code necessary. The generated code is thus ready to be compiled and deployed, or it can serve as a starting point and customized further with application specific logic. +カイアのコントラクトウィザードの様々な部分を探索した後、ご希望のコントラクトの種類を選択し（現在サポートされているのは、**KIP7**、**KIP17**、**KIP37**、**ERC20**、**ERC721**、**ERC1155**、**Governor**、およびカスタムコントラクト）、パラメータとご希望の機能（トークン名、シンボル、プレミント量、アクセス制御など）を設定すると、コントラクトウィザードが必要なコードをすべて生成します。 こうして生成されたコードは、すぐにコンパイルしてデプロイすることもできるし、出発点として利用し、アプリケーション固有のロジックでさらにカスタマイズすることもできる。 -## Customizing and Deploying Kaia Contracts on Kaia Network +## カイアネットワーク上でのカイア契約のカスタマイズと展開 -In this section, you will deploy the generated code from kaia contracts wizard to the Kaia Testnet Kairos using Foundry. The generated code will serve as a starting point and customized further to fit an airdrop contract for KIP7 and KIP17 tokens. While on the other end the generated code for KIP37 will be used as it is. +このセクションでは、Kaiaコントラクトウィザードから生成されたコードを、Foundryを使用してKaia Testnet Kairosにデプロイします。 生成されたコードは出発点となり、KIP7とKIP17トークンのエアドロップ契約に合わせてさらにカスタマイズされる。 もう一方では、KIP37用に生成されたコードがそのまま使われる。 -Let’s get started! +始めよう！ -### Prerequisites +### 前提条件 -To follow along in this tutorial, the prerequisites are highlighted below: +このチュートリアルに沿って進むために、前提条件を以下に示します： -- Make sure to have [foundry](https://book.getfoundry.sh/getting-started/installation) installed. -- Clone the [klaytn-foundry-starterkit](https://github.com/ayo-klaytn/klaytn-foundry-starterkit) code. -- [MetaMask](../tutorials/connecting-metamask.mdx#install-metamask): used to deploy the contracts, sign transactions and interact with the contracts. -- RPC Endpoint: you can get this from one of the supported [endpoint providers](../../references/public-en.md). -- Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. +- 必ず[foundry](https://book.getfoundry.sh/getting-started/installation)をインストールしてください。 +- [klaytn-foundry-starterkit](https://github.com/ayo-klaytn/klaytn-foundry-starterkit) コードをクローンします。 +- [MetaMask](../tutorials/connecting-metamask.mdx#install-metamask)：コントラクトのデプロイ、トランザクションへの署名、コントラクトとの対話に使用される。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](../../references/public-en.md)の1つから取得できます。 +- [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 -### Getting Started +### はじめに -This guide walks you through a simple implementation of an airdrop contract for KIP7 and KIP17 token standard. In the airdrop contract, the creator of the project mints each respective tokens directly to a certain selection of wallets. In the next sections, we will be looking at how to customize and deploy each token airdrop contract respectively. +このガイドでは、KIP7とKIP17トークン標準のエアドロップ契約の簡単な実装方法を説明します。 エアドロップ契約では、プロジェクトの作成者は、各トークンをウォレットの特定の選択に直接鋳造します。 次のセクションでは、それぞれのトークン・エアードロップ・コントラクトをカスタマイズし、デプロイする方法を見ていきます。 -### Customizing Token contracts +### トークン契約のカスタマイズ -**Customizing KIP7 contract to KIP7 Airdrop contract.** +\*\*KIP7契約をKIP7 Airdrop契約にカスタマイズする。 -You need to customize your KIP7 contract before modifying it to an airdrop contract. To do that, follow the steps below: +エアドロップ契約に変更する前に、KIP7契約をカスタマイズする必要があります。 そのためには、以下の手順に従ってください： -1. Navigate to [wizard.klaytn.foundation](https://wizard.klaytn.foundation/). -2. On the **Contracts** tab select **KIP7** -3. Next is to fill the name (KIP7 Token Airdrop) and symbol (KTA) in the **SETTINGS** tab. The pre-mint field is left empty -4. Subsequently on the **FEATURES** tab, tick the **Mintable** feature box, it then automatically selects the Ownable feature in **ACCESS CONTROL** tab. +1. [wizard.klaytn.foundation](https://wizard.klaytn.foundation/) に移動します。 +2. **契約**タブで**KIP7**を選択する。 +3. 次に、**SETTINGS**タブに名前(KIP7 Token Airdrop)とシンボル(KTA)を入力します。 プレミントの欄は空のまま +4. その後、**FEATURES**タブで**Mintable**機能にチェックを入れると、自動的に**ACCESS CONTROL**タブでOwnable機能が選択されます。 -This is how Kaia contracts wizard would look like after making these configurations: +これらの設定を行った後のカイアの契約ウィザードはこのようになる： ![](/img/build/tools/kip7-kcw.png) -Here is the generated code: +以下は生成されたコードである： ```solidity // SPDX-License-Identifier: MIT @@ -104,7 +104,7 @@ contract KIP7TokenAirdrop is KIP7, Ownable { } ``` -The next thing is to modify the code above to suit our airdrop implementation which looks like this: +次にすることは、上記のコードをエアドロップの実装に合うように修正することだ： ```solidity //SPDX-License-Identifier: MIT @@ -137,26 +137,26 @@ contract KIP7TokenAirdrop is KIP7, Ownable { } ``` -From the code modified above, you can see that we added a new function called `airdropTokens()`. This function mints tokens to certain selected addresses and can only be called by the creator of the contract - `onlyOwner`. +上で修正したコードから、`airdropTokens()`という新しい関数を追加したことがわかります。 この関数は特定の選択されたアドレスにトークンをミン トし、コントラクトの作成者である`onlyOwner`によってのみ呼び出される。 -Subsequently, we modified the _public_ **mint()** _onlyOwner_ function to **_mintSingleTokens()** private. +その後、_public_ **mint()** _onlyOwner_ 関数を **_mintSingleTokens()** private に変更しました。 -Now that we have our KIP7 airdrop contract code ready, the next step is to create a new file named airdropKIP7.sol in the src folder of your project directory and paste the modified code in the file. +KIP7エアドロップ契約コードの準備ができたので、次のステップは、プロジェクトディレクトリのsrcフォルダにairdropKIP7.solという名前の新しいファイルを作成し、修正したコードをそのファイルに貼り付けることです。 -**Customizing KIP17 contract to KIP17 Airdrop contract.** +\*\*KIP17契約をKIP17 Airdrop契約にカスタマイズする。 -You need to customize your KIP17 contract before modifying it to an airdrop contract. To do that, follow the steps below: +エアドロップ契約に変更する前に、KIP17契約をカスタマイズする必要があります。 そのためには、以下の手順に従ってください： -1. Navigate to [wizard.klaytn.foundation](https://wizard.klaytn.foundation/). -2. On the **Contracts** tab select **KIP17** -3. Next is to fill the name (KIP7 NFT Airdrop) and symbol (KNA) in the **SETTINGS** tab. The Base URI field is to be left empty. -4. Subsequently on the **FEATURES** tab, tick the **Mintable**, **Auto-increment Ids**, and **Enumerable** feature box. You will notice that the Ownable feature in **ACCESS CONTROL** tab has been automatically selected. +1. [wizard.klaytn.foundation](https://wizard.klaytn.foundation/) に移動します。 +2. **契約**タブで**KIP17**を選択する。 +3. 次に、**SETTINGS**タブに名前（KIP7 NFT Airdrop）と記号（KNA）を記入する。 Base URIフィールドは空のままにしておく。 +4. 続いて、**FEATURES** タブで、**Mintable**、**Auto-increment Ids**、**Enumerable** の各機能にチェックを入れます。 **ACCESS CONTROL**タブのOwnable機能が自動的に選択されていることがわかります。 -This is how Kaia contracts wizard would look like after making these configurations: +これらの設定を行った後のカイアの契約ウィザードはこのようになる： ![](/img/build/tools/kip17-kcw.png) -Here is the generated code: +以下は生成されたコードである： ```solidity // SPDX-License-Identifier: MIT @@ -192,7 +192,7 @@ contract KIP17NFTAirdrop is KIP17, KIP17Enumerable, Ownable { } ``` -The next thing is to modify the code above to suit our airdrop implementation which looks like this: +次にすることは、上記のコードをエアドロップの実装に合うように修正することだ： ```solidity // SPDX-License-Identifier: MIT @@ -235,26 +235,26 @@ contract KIP17NftAirdrop is KIP17, KIP17Enumerable, Ownable { } ``` -From the code modified above, you can see that we added a new function called **airdropNfts()**. This function mints tokens to certain selected addresses and can only be called by the creator of the contract - onlyOwner. +上で修正したコードから、\*\*airdropNfts()\*\*という新しい関数を追加したことがわかる。 この関数は、特定の選択されたアドレスにトークンを鋳造し、コントラクトの作成者であるonlyOwnerによってのみ呼び出される。 -Subsequently, we modified the **safeMint()** _public onlyOwner_ function to **_mintSingleTokens()** **private**. +その後、**safeMint()** _public onlyOwner_ 関数を **_mintSingleTokens()** **private** に変更しました。 -Now that we have our KIP17 airdrop contract code ready, the next step is to create a new file named airdropKIP17.sol in the src folder of your project directory and paste the modified code in the file. +KIP17のエアドロップ契約コードの準備ができたので、次のステップは、プロジェクト・ディレクトリのsrcフォルダにairdropKIP17.solという名前の新しいファイルを作成し、修正したコードをそのファイルに貼り付けることです。 -**Customizing KIP37 contract.** +\*\*KIP37契約のカスタマイズ -Because KIP37 supports batch minting, we will only customize the contract and use it as it is. To customize our KIP37Contract, follow the steps below: +KIP37は一括鋳造に対応しているため、契約書だけをカスタマイズしてそのまま使用する。 KIP37Contractをカスタマイズするには、以下の手順に従ってください： -1. Navigate to [wizard.klaytn.foundation.](https://wizard.klaytn.foundation/) -2. On the **Contracts** tab select **KIP37** -3. Next is to fill the name (KIP7 NFT Airdrop) and symbol (KNA) in the **SETTINGS** tab. The Base URI field is to be left empty. -4. Subsequently on the **FEATURES** tab, tick the **Mintable**, **Auto-increment Ids**, and **Enumerable** feature box. You will notice that the Ownable feature in **ACCESS CONTROL** tab has been automatically selected. +1. [wizard.klaytn.foundation.]に移動する(https://wizard.klaytn.foundation/) +2. 契約**タブで**KIP37\*\*を選択する。 +3. 次に、**SETTINGS**タブに名前（KIP7 NFT Airdrop）と記号（KNA）を記入する。 Base URIフィールドは空のままにしておく。 +4. 続いて、**FEATURES** タブで、**Mintable**、**Auto-increment Ids**、**Enumerable** の各機能にチェックを入れます。 **ACCESS CONTROL**タブのOwnable機能が自動的に選択されていることがわかります。 -This is how Kaia contracts wizard would look like after making these configurations: +これらの設定を行った後のカイアの契約ウィザードはこのようになる： ![](/img/build/tools/kip37-kcw.png) -Here is the generated code: +以下は生成されたコードである： ```solidity // SPDX-License-Identifier: MIT @@ -281,51 +281,51 @@ contract KIP37MultiToken is KIP37, Ownable { } ``` -Now that we have our KIP37 contract code ready, the next step is to create a new file named KIP37MultiToken.sol in the src folder of your project directory and paste the generated code in it. +KIP37コントラクト・コードの準備ができたので、次のステップは、プロジェクト・ディレクトリのsrcフォルダにKIP37MultiToken.solという名前の新しいファイルを作成し、生成されたコードを貼り付けることだ。 -Having generated the contract code for all our Kaia contracts, the next step is to deploy to the Kaia Testnet Kairos using Foundry solidity scripts. +すべてのKaiaコントラクトのコントラクトコードを生成した次のステップは、Foundry solidityスクリプトを使用してKaia Testnet Kairosにデプロイすることです。 -## Deploying generated smart contracts code using Foundry Scripts +## Foundryスクリプトを使用して生成されたスマートコントラクトコードをデプロイする -In this section we will go through deploying our generated smart contract code using Foundry; specifically the foundry script to deploy on-chain. +このセクションでは、生成したスマート・コントラクトのコードをFoundryを使ってデプロイする方法を説明します。 -### Getting Started +### はじめに -While getting started with foundry, you must have been exposed to the preliminary way of delaying contracts using [forge create](https://book.getfoundry.sh/reference/forge/forge-create.html). Recently, the Foundry team came up with a more user friendly way of declaratively deploying contracts using Solidity called [Solidity Scripting](https://book.getfoundry.sh/tutorials/solidity-scripting#solidity-scripting) i.e writing deployment scripts in solidity instead of JavaScript. +ファウンドリーを使い始めるにあたって、[forge create](https://book.getfoundry.sh/reference/forge/forge-create.html)を使って契約を遅らせるという予備的な方法に触れたはずだ。 最近、FoundryチームはSolidityを使用してコントラクトを宣言的にデプロイする、よりユーザーフレンドリーな方法として[Solidity Scripting](https://book.getfoundry.sh/tutorials/solidity-scripting#solidity-scripting)を開発しました。 -In this section, we will deploy our contract using solidity scripting in Foundry. +このセクションでは、Foundryのsolidityスクリプトを使用してコントラクトをデプロイします。 -### Environment Configuration +### 環境設定 -We’re going to deploy our generated smart contract to the Kaia Kairos Testnet, but to do this we’ll need to configure Foundry a bit, by setting things like a Kairos RPC URL, the private key of an account that’s funded with test KAIA. +生成したスマートコントラクトをKaia Kairosテストネットにデプロイするつもりですが、そのためにはKairos RPC URLやテストKAIAで資金調達しているアカウントの秘密鍵などを設定して、Foundryを少し設定する必要があります。 -Once you have all that, create a .env file and add the variables. Foundry automatically loads in a .env file present in your project directory. +それができたら、.envファイルを作成し、変数を追加する。 Foundryはプロジェクトディレクトリにある.envファイルを自動的に読み込みます。 -The .env file should follow this format: +.envファイルはこのフォーマットに従っている必要がある： ```code KAIROS_RPC_URL= -// if you want to deploy to mainnet +// メインネットにデプロイする場合 MAINNET_RPC_URL= PRIVATE_KEY= ``` -We now need to edit the `foundry.toml` file. There should already be one in the root of the project. Paste the following lines to the end of the file +次に`foundry.toml`ファイルを編集する必要がある。 プロジェクトのルートにすでに1つあるはずだ。 以下の行をファイルの最後に貼り付ける。 ```code [rpc_endpoints] kairos = "${KAIROS_RPC_URL}" -// if you want to deploy to mainnet +// メインネットにデプロイする場合 mainnet = "${MAINNET_RPC_URL}" ``` -### Writing the Script +### 脚本を書く -Next, we have to create a folder and name it script if it doesn’t already exist. We then need to create a script file for our contracts namely: +次に、フォルダを作成し、まだ存在していなければscriptという名前をつける。 airdropKIP7.s.sol airdropKIP17.s.sol KIP37MultiToken.s.sol -This is where we will write the deployment script itself. The contents of each file should look like this: +ここにデプロイスクリプト自体を記述する。 各ファイルの内容は以下のようになるはずだ： 1. airdropKIP7.s.sol @@ -400,31 +400,31 @@ contract KIP37MultiTokenDeployScript is Script { } ``` -Let’s go through what each line of code does. +各コード行が何をするのかを見ていこう。 -First we declared the SPDX-license and pragma version for each script file. Note that because each script file is a solidity program, we still need to declare the SPDX-license and pragma version, making it work like a smart contract, but is never deployed. +まず、各スクリプト・ファイルのSPDXライセンスとプラグマ・バージョンを宣言した。 各スクリプトファイルはsolidityプログラムであるため、SPDX-licenseとプラグマ・バージョンを宣言する必要があり、スマート・コントラクトのように動作するが、決してデプロイされないことに注意。 -Next we imported [Forge Std/Script.sol](https://github.com/foundry-rs/forge-std/blob/master/src/Script.sol) which provides some scripting utilities to use for deploying our contracts. Subsequently, we imported the contract to be deployed. In this case **airdropKIP7**, **airdropKIP17**, **KIP37MultiToken** for each script. +次に、コントラクトのデプロイに使用するスクリプト・ユーティリティを提供する[Forge Std/Script.sol](https://github.com/foundry-rs/forge-std/blob/master/src/Script.sol)をインポートしました。 その後、配備する契約をインポートした。 この場合、各スクリプトに対して、**airdropKIP7**、**airdropKIP17**、**KIP37MultiToken**を使用する。 -We then created a contract called **KIP7AirdropDeployScript**, **KIP17AirdropDeployScript**, **KIP37MultiTokenDeployScript** for each script file which inherits Script from Forge Std library. +次に、Forge Std ライブラリから Script を継承する各スクリプト ファイルに対して、**KIP7AirdropDeployScript**、**KIP17AirdropDeployScript**、**KIP37MultiTokenDeployScript** というコントラクトを作成しました。 -Next we declared the **run()** function. The function run() is the entry point for scripts to be executed. We -then declared a **deployerPrivateKey** variable that loads in the private key from our .env file. +次に、**run()**関数を宣言した。 run()関数は、スクリプトを実行するためのエントリー・ポイントである。 +次に、.envファイルから秘密鍵をロードする**deployerPrivateKey**変数を宣言します。 -Subsequently, we called the **vm.startBroadcast(deployerPrivateKey)** special cheat code that records calls and contract creations made by our main script contract, having passed the deployerPrivateKey for signing the transactions. +その後、\*\*vm.startBroadcast(deployerPrivateKey)\*\*という特殊なチートコードを呼び出し、メインスクリプト・コントラクトが行った呼び出しとコントラクトの作成を記録する。このコードは、トランザクションに署名するためのdeployerPrivateKeyを渡している。 -We then created the respective contract. This contract creation will be recorded by forge because we previously called the vm.startBroadcast() cheat code. +そして、それぞれの契約書を作成した。 以前にvm.startBroadcast()というチートコードを呼び出したので、このコントラクト作成はforgeによって記録される。 -Now that we have gotten an overview of what each line entails, you can move on to deploy the contracts. Click this [link](https://book.getfoundry.sh/tutorials/solidity-scripting#writing-the-script), to learn more about writing scripts and other details. +各ラインの概要が分かったところで、契約の展開に移ろう。 この[リンク](https://book.getfoundry.sh/tutorials/solidity-scripting#writing-the-script)をクリックして、スクリプトの書き方やその他の詳細をご覧ください。 -At the root of the project run +プロジェクトのルートで ```bash // To load the variables in the .env file source .env ``` -To deploy the each contract run the command below: +各契約をデプロイするには、以下のコマンドを実行する： 1. airdropKIP7 @@ -441,21 +441,21 @@ forge script script/airdropKIP17.s.sol:KIP17AirdropDeployScript --rpc-url $KAIRO 3. KIP37MultiToken ```bash -forge script script/KIP37MultiToken.s.sol:KIP37MultiTokenDeployScript --rpc-url $KAIROS_RPC_URL --broadcast --skip-simulation -vvvv +スクリプトを偽造する script/KIP37MultiToken.s.sol:KIP37MultiTokenDeployScript --rpc-url $KAIROS_RPC_URL --broadcast --skip-simulation -vvvv ``` -If the command was successful for each command, your terminal should look like this: +各コマンドが成功すれば、ターミナルは次のようになるはずだ： ![](/img/build/tools/deploy-kcw-contracts.png) -Refer to this [guide](https://book.getfoundry.sh/reference/forge/forge-script), to learn more about the script command. +スクリプトコマンドの詳細については、こちらの[ガイド](https://book.getfoundry.sh/reference/forge/forge-script)を参照してください。 -## Conclusion +## 結論 -In this tutorial, you learned about the Kaia contracts wizard, its functionality and how to customize contracts using KCW. This guide also demonstrated how to generate smart contract code and also how the generated smart contract code can serve as a starting point and customized further with application specific logic. +このチュートリアルでは、Kaiaコントラクトウィザードとその機能、KCWを使用したコントラクトのカスタマイズ方法について学びました。 このガイドでは、スマート・コントラクト・コードを生成する方法と、生成されたスマート・コントラクト・コードを出発点として、アプリケーション固有のロジックでさらにカスタマイズする方法も示した。 -Further, we deployed the generated contracts to Kaia Kairos Testnet using Foundry solidity scripting. You can make use of Remix IDE or any smart contract development environment to deploy smart contract derived or customized using from Kaia Contracts Wizard. You can find corresponding tutorials in the following links: +さらに、Foundry solidityスクリプトを使用して、生成されたコントラクトをKaia Kairos Testnetにデプロイしました。 Remix IDEやその他のスマートコントラクト開発環境を利用して、Kaiaコントラクトウィザードから派生またはカスタマイズしたスマートコントラクトをデプロイできます。 対応するチュートリアルは以下のリンクからご覧いただけます： -- [Connecting to Remix](../tutorials/connecting-remix.md#connecting-kaia-remix-using-metamask) -- [Deploying smart contract using Hardhat](../get-started/hardhat.md) -- [Deploying smart contract using Truffle](../smart-contracts/samples/erc-20.md#2-2-deploying-smart-contract-using-truffle) +- [リミックスにつなげる](../tutorials/connecting-remix.md#connecting-kaia-remix-using-metamask) +- [Hardhatを使用したスマートコントラクトのデプロイ](../get-started/hardhat.md) +- [Truffleを使用したスマートコントラクトのデプロイ](../smart-contracts/samples/erc-20.md#2-2-deploying-smart-contract-using-truffle) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md index 51ea15b33a62..6aea5570d26c 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md @@ -1,19 +1,19 @@ # Kaia Online Toolkit -## What is the Kaia Online Toolkit? +## カイアオンラインツールキットとは何ですか？ -- `Kaia Online Toolkit` provides code examples to help you to utilize the `Kaia SDK(caver-js)` easily. Also it provides a [demo page](https://toolkit.klaytn.foundation) for developers to use simple online tools. -- `Kaia SDK(caver-js)` is a JavaScript API library that allows developers to interact with a Kaia node using an HTTP or Websocket connection. -- You can just try out Kaia's features without having to code. +- `Kaia Online Toolkit`は、`Kaia SDK(caver-js)`を簡単に利用するためのコード例を提供します。 また、開発者が簡単なオンライン・ツールを使用するための[デモ・ページ](https://toolkit.klaytn.foundation)も提供している。 +- Kaia SDK(caver-js)\`は、開発者がHTTPまたはWebsocket接続を使ってKaiaノードとやりとりできるJavaScript APIライブラリです。 +- コードを書かなくても、カイアの機能を試すことができる。 -> To help more people use the `Kaia Online Toolkit`, We have prepared the ["Using Kaia Online Toolkit"](https://medium.com/klaytn/using-klaytn-online-toolkit-1-multisig-60399a0b0278) series. +> より多くの方に「カイアオンラインツールキット」をご利用いただくために、[「カイアオンラインツールキットを使う」](https://medium.com/klaytn/using-klaytn-online-toolkit-1-multisig-60399a0b0278)シリーズをご用意しました。 -## Links +## リンク -Here are the links for `Kaia Online Toolkit`. Feel free to use it :) +カイアオンラインツールキット\`のリンク集です。 ご自由にお使いください :) -- [Github Repository](https://github.com/kaiachain/kaia-online-toolkit) -- [Toolkit Page](https://toolkit.kaia.io) -- [Kaia SDK(caver-js)](../../references/sdk/caver-js/caver-js.md) +- [Githubリポジトリ](https://github.com/kaiachain/kaia-online-toolkit) +- [ツールキットページ](https://toolkit.kaia.io) +- [カイアSDK(caver-js)](../../references/sdk/caver-js/caver-js.md) ![Kaia Online Toolkit](/img/build/tools/klaytn-online-toolkit.png) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md index 00e2a2ec173d..19f66f9cd2af 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md @@ -1,12 +1,12 @@ -# Oracles +# 神託 -Blockchain oracles serve as a link between the blockchain and other external data sources. In actuality, the blockchain is a closed system; as such, it is unable to pull data into or out of any external systems (off-chain data) and only has access to data that is already present within the original blockchain context. This creates a blockchain-oracle issue where the blockchain is unable to obtain data from actual occurrences. Smart contracts must, however, connect to a wide range of external data sources in order to fulfill a number of useful functions. As an illustration, a [hybrid smart contract](https://chain.link/education-hub/hybrid-smart-contracts) that uses oracles to give asset prices for finance, weather data for insurance, randomness for gaming, IoT sensors for supply chain management, etc. +ブロックチェーンオークルは、ブロックチェーンと他の外部データソースをつなぐ役割を果たす。 実際のところ、ブロックチェーンはクローズド・システムであり、外部システム（オフチェーン・データ）にデータを取り込んだり、外部システムから取り出したりすることはできず、元のブロックチェーンのコンテキスト内にすでに存在するデータにしかアクセスできない。 これは、ブロックチェーンが実際に発生したデータを取得できないというブロックチェーン・オラクルの問題を引き起こす。 しかし、スマートコントラクトは、多くの有用な機能を果たすために、さまざまな外部データソースに接続しなければならない。 例として、[ハイブリッド・スマート・コントラクト](https://chain.link/education-hub/hybrid-smart-contracts)は、金融のための資産価格、保険のための気象データ、ゲームのためのランダム性、サプライチェーン管理のためのIoTセンサーなどを与えるために託宣を使用する。 -The need for blockchains to access and connect to external data sources, legacy systems, and advanced computation brought about oracles. The benefits of oracles in the blockchain industry cannot be underestimated, and it is therefore crucial to do your research before choosing your oracles when creating hybrid smart contracts. Avoiding centralized oracles is therefore encouraged since leveraging decentralized oracles is important for developing your decentralized apps. On one hand, centralized oracles are controlled by a single entity and, as such, have a single point of failure, making smart contracts vulnerable to attacks. On the other hand, decentralized oracles are designed to fly above the limitations of centralized oracles by eliminating the single point of failure. A decentralized oracle comprises multiple participants in a peer-to-peer network that form consensus on off-chain data before sending it to a smart contract. +ブロックチェーンが外部のデータソース、レガシーシステム、高度な計算にアクセスし、接続する必要性が、オラクルをもたらした。 ブロックチェーン業界におけるオラクルの利点は過小評価できないため、ハイブリッドスマートコントラクトを作成する際には、オラクルを選択する前に調査を行うことが極めて重要である。 分散型オラクルを活用することは分散型アプリを開発する上で重要であるため、中央集権型オラクルは避けることが推奨される。 一方では、中央集権的なオラクルは単一のエンティティによって制御されるため、単一障害点となり、スマートコントラクトを攻撃に対して脆弱にする。 一方、分散型オラクルは単一障害点を排除することで、集中型オラクルの限界を超えるように設計されている。 分散型オラクルは、スマートコントラクトにデータを送信する前に、オフチェーンデータについてコンセンサスを形成するピアツーピアネットワークの複数の参加者から構成される。 -The following providers have integrated with Klaytn to deliver decentralized oracle services: +以下のプロバイダーは、分散型オラクルサービスを提供するためにKaiaと統合しています： -- [Pyth Network](https://docs.pyth.network/home) +- [パイス・ネットワーク](https://docs.pyth.network/home) - [Orakl Network](https://docs.orakl.network) - [Witnet](https://docs.witnet.io/) - [SupraOracles](https://supraoracles.com/docs/overview) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md index 72f134717ac3..eab54dff49e2 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md @@ -1,29 +1,29 @@ -# Orakl Network +# オラクルネットワーク ![](/img/banners/kaia-orakl.png) -## Introduction +## はじめに -[Orakl Network](https://docs.orakl.network) is a decentralized oracle network that allows smart contracts to securely access off-chain data and other resources. It prides itself in being a native token oracle that provides [Data Feed](https://docs.orakl.network/developers-guide/data-feed), [VRF](https://docs.orakl.network/developers-guide/vrf), [Request-Response](https://docs.orakl.network/developers-guide/request-response) and [Proof of Reserve](https://docs.orakl.network/developers-guide/proof-of-reserve) solutions. +[オラクルネットワーク](https://docs.orakl.network)は、スマートコントラクトがオフチェーンのデータやその他のリソースに安全にアクセスできるようにする分散型オラクルネットワークである。 データフィード](https://docs.orakl.network/developers-guide/data-feed)、[VRF](https://docs.orakl.network/developers-guide/vrf)、[リクエスト・レスポンス](https://docs.orakl.network/developers-guide/request-response)、[プルーフ・オブ・リザーブ](https://docs.orakl.network/developers-guide/proof-of-reserve)のソリューションを提供するネイティブ・トークン・オラクルであることを誇りとしている。 -With Orakl Network, users can source for randomness that is unpredictable and unbiased in their smart contracts. Orakl Network [Verifiable Random Function (VRF)](https://docs.orakl.network/developers-guide/vrf#what-is-verifiable-random-function) allows smart contracts to generate verifiably random values, which can be used in various dApps that require randomness. Orakl Network provides developers access to the VRF services through two different account types, namely: [Permanent Account](https://docs.orakl.network/developers-guide/readme#permanent-account) or [Temporary Account](https://docs.orakl.network/developers-guide/readme#temporary-account). +Orakl Networkを使えば、ユーザーはスマートコントラクトに予測不可能で偏りのないランダム性を供給することができる。 Orakl Network [Verifiable Random Function (VRF)](https://docs.orakl.network/developers-guide/vrf#what-is-verifiable-random-function)は、スマートコントラクトが検証可能なランダム値を生成することを可能にし、ランダム性を必要とする様々なdAppsで使用することができる。 オラクルネットワークは、2つの異なるアカウントタイプを通じて、開発者にVRFサービスへのアクセスを提供します：[恒久アカウント](https://docs.orakl.network/developers-guide/readme#permanent-account)または[一時アカウント](https://docs.orakl.network/developers-guide/readme#temporary-account)です。 -In this tutorial, you will utilize the VRF functionality from Orakl Network to request for random words from inside of your smart contract. +このチュートリアルでは、Orakl NetworkのVRF機能を利用して、スマート・コントラクトの内部からランダムな単語をリクエストします。 -## Prerequisites +## 前提条件 -- [Kaia Wallet](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) +- [カイア・ウォレット](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) - [Remix IDE](https://remix.ethereum.org/) -- [Klaytn Plugin on Remix](https://klaytn.foundation/using-klaytn-plugin-on-remix/) -- Test KAIA from [Faucet](https://faucet.kaia.io) +- [KaiaプラグインをRemixで](https://klaytn.foundation/using-klaytn-plugin-on-remix/) +- [Faucet](https://faucet.kaia.io)からKAIAをテストする。 -## Getting Started +## はじめに -In the following steps, you will request for a random word in your smart contract using Orakl Network. Let's get started! +以下のステップでは、Orakl Networkを使ってスマート・コントラクトにランダムな単語を要求する。 始めよう！ -### Step 1: Initialize Contract State Variables +### ステップ1：契約状態変数の初期化 -In this step, we will define the cosumer contract and initialize the state variables needed for our contract functionality. Our consumer contract is dependent on `VRFConsumerBase` contract from which we inherit, and `IVRFCoordinator` interface that is used for calls to `VRFCoordinator` contract. Next, we define `sRandomWord` variable which we use to store the random word result and the `sOwner` variable which is used inside of `onlyOwner` modifier. +このステップでは、Cosumerコントラクトを定義し、コントラクト機能に必要なステート変数を初期化する。 私たちのコンシューマ契約は `VRFConsumerBase` 契約に依存しており、この契約は `VRFCoordinator` 契約への呼び出しに使用される `IVRFCoordinator` インターフェースに継承されています。 次に、ランダムワードの結果を格納する変数 `sRandomWord` と、修飾子 `onlyOwner` の内部で使用する変数 `sOwner` を定義する。 ```solidity pragma solidity ^0.8.16; @@ -44,9 +44,9 @@ contract VRFConsumer is VRFConsumerBase { } ``` -### Step 2: Initialize VRF Coordinator +### ステップ 2：VRF コーディネーターの初期化 -To request for random words in your smart contract, you need to initialize the [`VRFCoordinator`](https://github.com/Bisonai/orakl/blob/master/contracts-v0.1/src/v0.1/VRFCoordinator.sol) smart contract. It is recommended to bond `VRFCoordinator` interface with `VRFCoordinator` address supplied through a constructor parameter, and use it for random word requests (`requestRandomWords`). The `VRFCoordinator` contract is deployed both on Kaia Kairos [0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499](https://kairos.kaiascan.io/account/0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499) and Kaia Mainnet [0x3F247f70DC083A2907B8E76635986fd09AA80EFb](https://www.kaiascan.io/account/0x3F247f70DC083A2907B8E76635986fd09AA80EFb). +スマートコントラクトでランダムな単語を要求するには、[`VRFCoordinator`](https://github.com/Bisonai/orakl/blob/master/contracts-v0.1/src/v0.1/VRFCoordinator.sol) スマートコントラクトを初期化する必要がある。 `VRFCoordinator` インターフェースは、コンストラクタのパラメータで `VRFCoordinator` のアドレスを指定して結合し、ランダムワードのリクエスト (`requestRandomWords`) に使用することを推奨する。 `VRFCoordinator`コントラクトはKaia Kairos [0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499](https://kairos.kaiascan.io/account/0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499)とKaia Mainnet [0x3F247f70DC083A2907B8E76635986fd09AA80EFb](https://www.kaiascan.io/account/0x3F247f70DC083A2907B8E76635986fd09AA80EFb)の両方に配備されている。 ```solidity IVRFCoordinator COORDINATOR; @@ -57,7 +57,7 @@ To request for random words in your smart contract, you need to initialize the [ } ``` -### Step 3: Request Random Words with Temporary Account +### ステップ 3: 一時的なアカウントでランダムワードをリクエストする To request random words with a temporary account, users need to send $KLAY together with a call using value property. @@ -82,11 +82,11 @@ To request random words with a temporary account, users need to send $KLAY toget } ``` -This function calls the `requestRandomWords()` function defined in `COORDINATOR` contract, and passes `keyHash`, `callbackGasLimit`, `numWords` and `refundRecipient` as arguments. The payment for service is sent through `msg.value` to the `requestRandomWords()` in `COORDINATOR` contract. If the payment is larger than expected payment, exceeding payment is returned to the `refundRecipient` address. Eventually, it generates a request for random words. To accurately specify `msg.value` for the `requestRandomWords` function, please refer to the explanation on [how to estimate the service fee](https://docs.orakl.network/developers-guide/vrf#get-estimated-service-fee). +この関数は `COORDINATOR` で定義された関数 `requestRandomWords()` を呼び出し、引数として `keyHash`、`callbackGasLimit`、`numWords` および `refundRecipient` を渡す。 サービスに対する支払いは `msg.value` を通して `COORDINATOR` 契約の `requestRandomWords()` に送られる。 もし支払いが予定より多かった場合、超過分の支払いは `refundRecipient` アドレスに返される。 最終的には、ランダムな単語のリクエストを生成する。 `requestRandomWords`関数の`msg.value`を正確に指定するには、[サービス料金の見積もり方法](https://docs.orakl.network/developers-guide/vrf#get-estimated-service-fee)の説明を参照してください。 -### Step 4: Fulfill Random Words +### ステップ4：ランダムな言葉を満たす -The `fulfillRandomWords` function is called by `VRFCoordinator` contract when fulfilling the random words request. +`fulfillRandomWords`関数は、`VRFCoordinator`コントラクトがランダムワードの要求を満たすときに呼び出される。 ```solidity function fulfillRandomWords( @@ -102,27 +102,27 @@ function fulfillRandomWords( } ``` -Now that we have the Orakl VRF solution code, let’s get to see it in action. +それでは、Orakl VRFソリューションのコードを手に入れたので、実際に使ってみましょう。 -## Practical Implementation +## 実践的な実施 -In the example below, the contract allows us to request for random words and receive its fulfillment. +下の例では、ランダムな単語を要求し、その成就を受け取ることができる契約になっている。 -### Create and Deploy Sample Code +### サンプルコードの作成とデプロイ **Remix IDE** -- Navigate to [Remix IDE](https://remix.ethereum.org/). -- Click on the **File Explorer** tab, create a new file named `consumer-vrf.sol` in the contracts folder. -- Paste the code below in your newly created file. -- In Remix, click **Compile contract**. -- Click the Klaytn tab on your left having installed the plugin. -- Select **Environment** > **Injected Provider** - **Kaia Wallet**. -- In **Contract**, select your contract. For example, `VRFConsumer`. -- Pass in the coordinator contract address `0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499` (Baobab), `0x3F247f70DC083A2907B8E76635986fd09AA80EFb` (Cypress). -- Click **Deploy**. +- Remix IDE](https://remix.ethereum.org/)に移動します。 +- ファイルエクスプローラー\*\*タブをクリックし、contractsフォルダに`consumer-vrf.sol`という名前のファイルを新規作成する。 +- 新しく作成したファイルに以下のコードを貼り付けます。 +- Remixで、**Compile contract**をクリックします。 +- プラグインをインストールしたら、左側の「Kaia」タブをクリックします。 +- **Environment** > **Injected Provider** - **Kaia Wallet** を選択します。 +- **Contract**で、契約を選択します。 例えば、`VRFConsumer`である。 +- コーディネーター契約アドレス `0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499` (Kairos), `0x3F247f70DC083A2907B8E76635986fd09AA80EFb` (Mainnet) を渡す。 +- **Deploy**をクリックします。 -**Sample Code** +**サンプルコード** ```solidity // SPDX-License-Identifier: MIT @@ -178,31 +178,31 @@ contract VRFConsumer is VRFConsumerBase { ![](/img/build/tools/orakl-vrf-deploy.png) -### Interact with Smart Contract +### スマートコントラクトとの対話 -To request for random words in your smart contract, you have to first execute the `requestRandomWordsDirect()` function. For this function to successfully execute, the user has to send KLAY (minimum of 1 KLAY) as stated previously, and supply `keyHash`, `callbackGasLimit`, `numWords`, and `refundRecipient` parameters. `keyHash` parameter uniquely defines who can fulfill the request. Orakl Network VRF provides one key hash for each Klaytn chain: +スマート・コントラクトでランダムな単語を要求するには、まず `requestRandomWordsDirect()` 関数を実行しなければならない。 この関数が正常に実行されるためには、ユーザは前述のようにKAIAを送信し(最低1KAIA)、 `keyHash`、`callbackGasLimit`、`numWords`、`refundRecipient`パラメータを与える必要がある。 `keyHash`パラメータは、誰がリクエストを処理できるかを一意に定義する。 Orakl Network VRFは、Kaiaチェーンごとに1つのキーハッシュを提供します： - Kairos: `0xd9af33106d664a53cb9946df5cd81a30695f5b72224ee64e798b278af812779c` - Mainnet: `0x6cff5233743b3c0321a19ae11ab38ae0ddc7ddfe1e91b162fa8bb657488fb157` -For the rest of the parameters, you can set them as follows: +残りのパラメーターは、以下のように設定することができる： -- `callbackGasLimit` as `500000`, -- `numWords` as `1`, and -- set `refundRecipient` to your EOA address. +- `callbackGasLimit`を`500000`とする、 +- `numWords`を`1`、そして +- `refundRecipient`にEOAのアドレスを設定します。 -Afterwards, once the request has been fulfilled, the `sRandomWord()` function can be executed. This `sRandomWord()` function returns the random word. +その後、リクエストが満たされると、 `sRandomWord()` 関数を実行することができる。 この `sRandomWord()` 関数はランダムな単語を返す。 -- **requestRandomWordsDirect()**: Will be sending 1 KLAY to execute this function. The image below illustrate this: +- **requestRandomWordsDirect()**: Will be sending 1 KLAY to execute this function. 下の画像がそれを示している： ![](/img/build/tools/orakl-vrf-request.png) -- **sRandomWord()**: After the `VRFCoordinator` has fulfilled the random word request, the response is stored in the `sRandomWord` variable. To get the response, call the `sRandomWord()` function. +- \*\*sRandomWord()\*\*である：VRFCoordinator`がランダムワードの要求を満たすと、そのレスポンスが `sRandomWord`変数に格納される。 レスポンスを得るには、関数`sRandomWord()\` を呼び出す。 ![](/img/build/tools/orakl-vrf-response.png) -Tada 🎉! You just requested for a random word and received one in your smart contract. +多田🎉！ ランダムな単語を要求し、スマート・コントラクトで受け取っただけだ。 -## Conclusion +## 結論 -In this tutorial, you learnt how to generate a random word in your smart contract using the Orakl Network VRF solution. The Orakl Network provides more oracle services such as Data Feed, Request-Response, Proof of Reserve. For more in-depth guides on Orakl Network and how it works, please refer to the [Orakl Network documentation](https://docs.orakl.network). +このチュートリアルでは、Orakl Network VRFソリューションを使用してスマートコントラクトにランダムな単語を生成する方法を学びました。 オラクルネットワークは、データフィード、リクエスト・レスポンス、プルーフ・オブ・リザーブなど、より多くのオラクルサービスを提供する。 オラクルネットワークの詳細および動作については、[オラクルネットワークのドキュメント](https://docs.orakl.network)を参照してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md index 4f86b4e72271..b34b141ba627 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md @@ -1,21 +1,21 @@ -# Pyth Network +# パイス・ネットワーク ![](/img/banners/kaia-pyth.png) -## Overview +## 概要 -The [Pyth Network](https://pyth.network/) is one of the largest first-party Oracle network, delivering real-time data across [a vast number of chains](https://docs.pyth.network/price-feeds/contract-addresses). +Pyth Network](https://pyth.network/)は最大級のファーストパーティ・オラクル・ネットワークで、[膨大な数のチェーン](https://docs.pyth.network/price-feeds/contract-addresses)にリアルタイム・データを配信している。 -The network comprises some of the world’s [largest exchanges, market makers, and financial services providers](https://pyth.network/publishers). These publish proprietary data on-chain for aggregation and distribution to smart contract applications. +このネットワークは、世界最大級の[取引所、マーケットメーカー、金融サービスプロバイダー]で構成されている(https://pyth.network/publishers)。 これらは、スマート・コントラクト・アプリケーションに集計・配信するために、独自のデータをチェーン上で公開する。 -## Using Pyth Network +## Pythネットワークを使う -The Pyth introduces an innovative low-latency [pull oracle design](https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand), where users can pull price updates onchain when needed, enabling everyone in the onchain environment to access that data point most efficiently. Pyth network updates the prices every **400ms**, making Pyth one of the fastest on-chain oracles. +Pythは革新的な低レイテンシー[プルオラクルデザイン](https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand)を導入しており、ユーザーは必要なときにオンチェーンで価格更新をプルすることができ、オンチェーン環境にいる全員が最も効率的にそのデータポイントにアクセスすることができる。 Pythネットワークは**400ms**ごとに価格を更新し、Pythを最速のオンチェーンオークルの1つにしています。 -Developers on Kaia have permissionless access to any of [Pyth’s price feeds](https://pyth.network/developers/price-feed-ids) for equities, ETFs, commodities, foreign exchange pairs, and cryptocurrencies. +カイアの開発者は、株式、ETF、コモディティ、外国為替ペア、暗号通貨の[Pyth's price feeds](https://pyth.network/developers/price-feed-ids)のいずれにも無許可でアクセスできます。 -Here is a working example of a contract that fetches the latest price of ETH/USD on the Kaia network. -You have to pass [Pyth's contract address](https://docs.pyth.network/price-feeds/contract-addresses/evm) for Kaia mainnet/testnet and the desired [price feed id](https://pyth.network/developers/price-feed-ids) to fetch the latest price. +以下は、Kaiaネットワーク上のETH/USDの最新価格をフェッチするコントラクトの動作例です。 +最新の価格を取得するには、カイアのメインネット/テストネット用の[Pyth's contract address](https://docs.pyth.network/price-feeds/contract-addresses/evm)と希望の[price feed id](https://pyth.network/developers/price-feed-ids)を渡す必要があります。 ```solidity // SPDX-License-Identifier: UNLICENSED @@ -46,37 +46,37 @@ contract MyFirstPythContract { } ``` -Here you can fetch the `updateData` from our [`Hermes`](https://hermes.pyth.network/docs/), which listens to Pythnet and Wormhole for price updates; or you can use the [`pyth-evm-js`](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/js/src/EvmPriceServiceConnection.ts#L15) SDK. Check [How to Fetch Price Updates](https://docs.pyth.network/price-feeds/fetch-price-updates) to pull the latest data. +ここでは、価格更新のためにPythnetとWormholeをリッスンする[`Hermes`](https://hermes.pyth.network/docs/)から`updateData`を取得することができます。また、[`pyth-evm-js`](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/js/src/EvmPriceServiceConnection.ts#L15)のSDKを使用することもできます。 価格更新の取得方法](https://docs.pyth.network/price-feeds/fetch-price-updates)を確認し、最新のデータを取得してください。 -This [package](https://github.com/pyth-network/pyth-crosschain/tree/main/target_chains/ethereum/sdk/solidity) provides utilities for consuming prices from the Pyth network oracle using Solidity. Also, it contains the [Pyth Interface ABI](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/solidity/abis/IPyth.json) that you can use in your libraries to communicate with the Pyth contract. +この[パッケージ](https://github.com/pyth-network/pyth-crosschain/tree/main/target_chains/ethereum/sdk/solidity)は、Solidityを使用してPythネットワークオラクルから価格を消費するためのユーティリティを提供します。 また、[Pyth Interface ABI](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/solidity/abis/IPyth.json)も含まれており、Pythコントラクトと通信するためにライブラリで使用することができます。 -We recommend following the [consumer best practices](https://docs.pyth.network/documentation/pythnet-price-feeds/best-practices) when consuming Pyth data. +Pyth データを利用する際には、[consumer best practices](https://docs.pyth.network/documentation/pythnet-price-feeds/best-practices)に従うことを推奨します。 -For more information, check out the official [Pyth documentation](https://docs.pyth.network/price-feeds). There are details on the various functions available for interacting with the Pyth smart contract in the [API Reference section](https://api-reference.pyth.network/price-feeds/evm/getPrice). +詳しくは公式の[Pyth documentation](https://docs.pyth.network/price-feeds)を参照してください。 Pythスマートコントラクトとやりとりするために利用できるさまざまな関数については、[APIリファレンスセクション](https://api-reference.pyth.network/price-feeds/evm/getPrice)に詳細があります。 -## Pyth on Kaia +## カイアのピース -The Pyth Network smart contract is available at the following address: +Pyth Networkのスマートコントラクトは以下のアドレスで入手できる： -- Mainnet: [0x2880ab155794e7179c9ee2e38200202908c17b43](https://kaiascan.io/account/0x2880aB155794e7179c9eE2e38200202908C17B43) -- Kairos Testnet: [0x2880ab155794e7179c9ee2e38200202908c17b43](https://kairos.kaiascan.io/account/0x2880aB155794e7179c9eE2e38200202908C17B43) +- メインネット[0x2880ab155794e7179c9ee2e38200202908c17b43](https://kaiascan.io/account/0x2880aB155794e7179c9eE2e38200202908C17B43) +- カイロス・テストネット[0x2880ab155794e7179c9ee2e38200202908c17b43](https://kairos.kaiascan.io/account/0x2880aB155794e7179c9eE2e38200202908C17B43) -Additionally, click to access the [Pyth price-feed IDs](https://pyth.network/developers/price-feed-ids). +さらに、クリックすると[Pyth price-feed IDs](https://pyth.network/developers/price-feed-ids)にアクセスできる。 -## Using Pyth as a PUSH Oracle +## PythをPUSHオラクルとして使う -Pyth Oracle can be used as a Push oracle by running a scheduler which can update the prices in the backend. It will make sure that the your dapp will be updated with latest prices as per your configuration. Checkout the open source [price pusher](https://github.com/pyth-network/pyth-crosschain/tree/main/apps/price_pusher) app to get started with the scheduler. +Pythオラクルは、バックエンドの価格を更新するスケジューラを実行することで、プッシュオラクルとして使用することができる。 これは、あなたのダップがあなたの設定に従って最新の価格で更新されることを保証します。 スケジューラを始めるには、オープンソースの[price pusher](https://github.com/pyth-network/pyth-crosschain/tree/main/apps/price_pusher)アプリをチェックしよう。 -## Developers and community +## 開発者とコミュニティ -The Pyth network provides additional tools to developers, such as [TradingView Integration](https://docs.pyth.network/guides/how-to-create-tradingview-charts), or the [Gelato web3 functions](https://docs.pyth.network/guides/how-to-schedule-price-updates-with-gelato). +Pythネットワークは、[TradingView Integration](https://docs.pyth.network/guides/how-to-create-tradingview-charts)や[Gelato web3 functions](https://docs.pyth.network/guides/how-to-schedule-price-updates-with-gelato)のような追加ツールを開発者に提供しています。 -Check out the following links to get started with Pyth. +Pythを始めるには以下のリンクをチェックしてください。 -- [Pyth EVM Integration Guide](https://docs.pyth.network/price-feeds/use-real-time-data/evm) +- [Pyth EVM 統合ガイド](https://docs.pyth.network/price-feeds/use-real-time-data/evm) - [Pyth Docs](https://docs.pyth.network/home) -- [Pyth API Reference](https://api-reference.pyth.network/price-feeds/evm/getPrice) +- [Pyth APIリファレンス](https://api-reference.pyth.network/price-feeds/evm/getPrice) - [Pyth Examples](https://github.com/pyth-network/pyth-examples) - [Pyth Price Feed Ids](https://pyth.network/developers/price-feed-ids) -- [Website](https://pyth.network/) -- [Twitter](https://x.com/PythNetwork) +- [ウェブサイト](https://pyth.network/) +- [ツイッター](https://x.com/PythNetwork) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md index 3287b1a87dd8..edcc3ad95433 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md @@ -2,26 +2,26 @@ ![](/img/banners/kaia-supra.png) -## Introduction +## はじめに -[SupraOracles](https://supraoracles.com/) is a novel, high-throughput Oracle & IntraLayer: a vertically integrated toolkit of cross-chain solutions (data oracles, asset bridges, automation network, and more) that interlink all blockchains, public (L1s and L2s) or private (enterprises). It provides smart contracts with a next-generation cross chain oracle solution that has superior data accuracy, speed, scalability and security. +[SupraOracles](https://supraoracles.com/)は、新しい、高スループットのオラクル＆イントラレイヤー：パブリック（L1とL2）またはプライベート（企業）のすべてのブロックチェーンを相互リンクするクロスチェーンソリューション（データオラクル、アセットブリッジ、オートメーションネットワークなど）の垂直統合ツールキットです。 スマートコントラクトに、データ精度、スピード、スケーラビリティ、セキュリティに優れた次世代クロスチェーン・オラクル・ソリューションを提供する。 -With SupraOracles, your smart contract can get access to price data feeds to build your various decentralized finance(DeFi) use cases. In this tutorial, you will use SupraOracles to get price feeds easily on Klaytn blockchain using Remix IDE. +SupraOraclesを使えば、スマートコントラクトは価格データフィードにアクセスし、様々な分散型金融（DeFi）のユースケースを構築することができます。 このチュートリアルでは、Remix IDEを使ってKaiaブロックチェーンの価格フィードを簡単に取得するためにSupraOraclesを使用します。 -## Prerequisites +## 前提条件 -- [Kaia Wallet](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) +- [カイア・ウォレット](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) - [Remix IDE](https://remix.ethereum.org/) -- [Klaytn Plugin on Remix](https://klaytn.foundation/using-klaytn-plugin-on-remix/) -- Test KAIA from [Faucet](https://faucet.kaia.io) +- [KaiaプラグインをRemixで](https://klaytn.foundation/using-klaytn-plugin-on-remix/) +- [Faucet](https://faucet.kaia.io)からKAIAをテストする。 -## Getting Started +## はじめに -In the following steps, you will request an ETH/USD price feed in your smart contract using SupraOracles. Let's get started! +以下のステップでは、SupraOraclesを使用してスマートコントラクトにETH/USD価格フィードを要求します。 始めよう！ -### Step 1: Create The S-Value Interface +### ステップ1：S値インタフェースの作成 -This creates the interface that will be used to fetch prices from SupraOracles. Add the following code to the solidity smart contract that you wish to retrieve an S-Value. +これは、SupraOraclesから価格を取得するために使用されるインターフェイスを作成します。 S-Valueを取得したいsolidityスマートコントラクトに以下のコードを追加する。 ```solidity interface ISupraSValueFeed { @@ -29,9 +29,9 @@ function checkPrice(string memory marketPair) external view returns (int256 pric } ``` -### Step 2: Configure The S-Value Feed Address +### ステップ2：S値フィードアドレスの設定 -To fetch the S-Value from a SupraOracles smart contract, first find the S-Value Feed Address for the chain of your choice. When you have the right address, create an instance of the S-Value Feed using the interface we previously defined as such: +SupraOraclesスマートコントラクトからS-Valueを取得するには、まず選択したチェーンのS-Valueフィードアドレスを見つけます。 適切なアドレスが得られたら、先に定義したインターフェイスを使用してS-Value Feedのインスタンスを作成する： ```solidity contract ISupraSValueFeedExample { @@ -42,11 +42,11 @@ contract ISupraSValueFeedExample { } ``` -In this example, we are implementing the S-Value Feed on the Klaytn Baobab TestNet. You can verify the Klaytn Baobab S-Value Feed Address [here](https://supraoracles.com/docs/get-started/networks/). +この例では、Kaia Kairos TestNetにS-Value Feedを実装しています。 カイア・カイロスS-Valueのフィードアドレスは[こちら](https://supraoracles.com/docs/get-started/networks/)で確認できます。 -### Step 3: Get The S-Value Crypto Price +### ステップ3: S-Value暗号価格を取得する -Now you can simply access the S-Value Crypto Price of our supported market pairs. In this step, you'll get the price of ETH/USDT (eth_usdt) by applying the following code to your Smart Contract. +S-Valueの暗号化通貨ペアに簡単にアクセスできるようになりました。 このステップでは、スマートコントラクトに以下のコードを適用することで、ETH/USDT（eth_usdt）の価格を取得します。 ```solidity function getEthUsdtPrice() external view returns (int) { @@ -58,24 +58,24 @@ return price; } ``` -## Practical implementation +## 実践 -In the example below, we will be deploying the S-Value Price Feed Contract and also executing the getEthUsdtPrice() function to get the price ETH/USDT pairs. +以下の例では、S-Value Price Feed Contract をデプロイし、getEthUsdtPrice() 関数を実行して ETH/USDT ペアの価格を取得します。 -### Create and Deploy Sample Code +### サンプルコードの作成とデプロイ **Remix IDE** -- Navigate to [Remix IDE](https://remix.ethereum.org/) -- Click on File Explorer tab, create a new file named `demoSupraPriceFeed.sol` in the contracts folder -- Paste the code below in your newly created file -- In Remix, click **Compile contract**. -- Click the Klaytn tab on your left having installed the plugin -- Select **Environment** > **Injected Provider** - **Kaia Wallet**. -- In **Contract**, select your contract. For example, ISupraSValueFeedExample. -- Click **Deploy**. +- Remix IDE](https://remix.ethereum.org/) に移動する。 +- ファイルエクスプローラタブをクリックし、contractsフォルダに`demoSupraPriceFeed.sol`という新しいファイルを作成する。 +- 新しく作成したファイルに以下のコードを貼り付けます。 +- Remixで、**Compile contract**をクリックします。 +- プラグインをインストールしたら、左側のKaiaタブをクリックします。 +- **Environment** > **Injected Provider** - **Kaia Wallet** を選択します。 +- **Contract**で、契約を選択します。 例えば、ISupraSValueFeedExample。 +- **Deploy**をクリックします。 -**Sample Code** +**サンプルコード** ```solidity // SPDX-License-Identifier: MIT @@ -98,19 +98,19 @@ contract ISupraSValueFeedExample { } ``` -### Interact with Smart Contract +### スマートコントラクトとの対話 -To get the price feed for the selected currency pair, you have to execute the `getEthUsdtPrice()` function. +選択した通貨ペアの価格フィードを取得するには、`getEthUsdtPrice()`関数を実行する必要があります。 ![](/img/build/tools/sPriceFeed.png) -Tada 🎉! You just requested for a currency price feed (ETH/USDT) in your smart contract. +多田🎉！ スマートコントラクトに通貨価格のフィード（ETH/USDT）を要求しました。 -As of the time of writing, getEthUsdtPrice() returned "185795966200", an 8-point precision figure. To get the actual ETH/USD value, you need to divide the figure by 10^8 which equals $1857.95966200. +本稿執筆時点では、getEthUsdtPrice()は "185795966200 "という8ポイント精度の数値を返している。 実際のETH/USDの値を得るには、この数字を10^8で割る必要があり、これは$1857.95966200に相当する。 -## More Ways To Use SupraOracles Crypto Price Feeds +## SupraOraclesの暗号通貨価格フィードを利用するその他の方法 -### S-Value Feeds With Web3.js +### Web3.jsによるS-Valueフィード ```javascript // example assumes that the web3 library has been imported and is accessible within your scope @@ -125,7 +125,7 @@ console.log(`The price is: ${price}`) getEthUsdtPrice() ``` -### S-Value Feeds With ethers.js +### ethers.jsによるS-Valueフィード ```javascript // example assumes that the ethers library has been imported and is accessible within your scope @@ -143,6 +143,6 @@ console.log(`The price is: ${price.toString()}`) getEthUsdtPrice() ``` -## Conclusion +## 結論 -In this tutorial, you learned how to request an ETH/USD price using the SupraOracle price feed solution. With SupraOracle, you can also generate random numbers in your smart contract. Curious about this process, visit this [guide](https://metaverse-knowledge-kit.klaytn.foundation/docs/decentralized-oracle/oracle-providers/supraOracles-tutorial) on integrating SupraVRF on Klaytn. For more in-depth guides on SupraOracles, please refer to the [SupraOracles Docs](https://supraoracles.com/docs/development-guides). +このチュートリアルでは、SupraOracle 価格フィードソリューションを使用して ETH/USD 価格を要求する方法を学びました。 SupraOracleを使えば、スマートコントラクト内で乱数を生成することもできる。 このプロセスに興味がある方は、カイアにSupraVRFを統合するための[ガイド](https://metaverse-knowledge-kit.klaytn.foundation/docs/decentralized-oracle/oracle-providers/supraOracles-tutorial)をご覧ください。 SupraOraclesに関するより詳細なガイドについては、[SupraOracles Docs](https://supraoracles.com/docs/development-guides) を参照してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md index 5085cb2675e8..c481e52ffd05 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md @@ -2,14 +2,14 @@ ![](/img/banners/kaia-witnet.png) -## Introduction +## はじめに -The [Witnet](https://docs.witnet.io/) multichain decentralized oracle enables smart contracts to actualize their potential by providing them access to all sorts of valuable external data sets. These valuable data sets include sports results, stock prices, weather forecasts, randomness, et al. -To offer decentralized oracle services, Witnet relies on a distributed network of peer nodes— colloquially called witnesses—who earn Wit tokens as a reward for retrieving web data and reporting it directly to the smart contracts. The witnesses are responsible for sourcing, retrieving, and verifying the data sets. To ensure transparency, each anonymous peer is incentivized to report the retrieved data honestly and is punished or slashed for any wrongdoing. +Witnet](https://docs.witnet.io/)のマルチチェーン分散型オラクルは、あらゆる種類の貴重な外部データセットへのアクセスを提供することで、スマートコントラクトがその潜在能力を発揮できるようにする。 こうした価値あるデータセットには、スポーツの結果、株価、天気予報、ランダム性などが含まれる。 +。分散型のオラクルサービスを提供するため、ウィットネットはピアノード（俗に証人と呼ばれる）の分散ネットワークに依存している。彼らはウェブデータを取得し、スマートコントラクトに直接報告することで報酬としてウィットトークンを獲得する。 立会人は、データセットの調達、検索、検証を担当する。 透明性を確保するため、各匿名ピアは検索されたデータを正直に報告するよう奨励され、不正を行った場合は罰せられるか、切り捨てられる。 -## Usage +## 使用方法 -This oracle network is currently running on the Klaytn Cypress Mainnet and Klaytn Baobab Testnet. To get started with connecting to the data feeds and randomness on Klaytn, refer to the following guides: +このオラクルネットワークは現在、KaiaメインネットとKaia Kairosテストネットで稼働している。 カイアのデータフィードとランダム性への接続を開始するには、以下のガイドを参照してください： -- [Witnet Price-Feed Tutorial](https://metaverse-knowledge-kit.klaytn.foundation/docs/decentralized-oracle/oracle-providers/witnet-tutorial) +- [ウィットネット・プライス・フィード・チュートリアル](https://metaverse-knowledge-kit.klaytn.foundation/docs/decentralized-oracle/oracle-providers/witnet-tutorial) - [Random Number Generation on Klaytn with Witnet](https://medium.com/klaytn/random-number-generation-on-klaytn-with-witnet-ae136dad0562) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/tools.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/tools.md index 4af5a0003ad8..6a4e8da19be5 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/tools.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/tools.md @@ -1,6 +1,6 @@ -# Tools +# ツール -This page contains the list of development tools to help you build Decentralized Applications on Klaytn. +このページには、カイア上で分散型アプリケーションを構築するための開発ツールのリストが含まれています。 ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md index e7eb0cfc6fa8..62558923e9e5 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md @@ -1,13 +1,13 @@ -# D'cent Biometric Wallet +# ディセント・バイオメトリック・ウォレット -## Introduction +## はじめに -D'Cent Wallet is a non-custodial biometric wallet designed to offer both Bluetooth-enabled hardware and software options to manage your crypto with ease. +D'Cent Walletは、暗号を簡単に管理できるよう、Bluetooth対応のハードウェアとソフトウェアの両方のオプションを提供するように設計された、非保護型のバイオメトリック・ウォレットです。 -Get a D'CENT device in their [offical website](https://store.dcentwallet.com/pages/dcent-biometric-crypto-wallet) +公式サイト](https://store.dcentwallet.com/pages/dcent-biometric-crypto-wallet)でD'CENTのデバイスを入手しよう。 -## Guide +## ガイド -- [Setup](https://userguide.dcentwallet.com/biometric-wallet/setting-up) -- [How to send and receive Kaia](https://userguide.dcentwallet.com/coin-send-receive/coins/klaytn-klay#how-to-create-an-klay-account) -- [Connect with Kaia Wallet](https://userguide.dcentwallet.com/external-service/kaikas) +- [セットアップ](https://userguide.dcentwallet.com/biometric-wallet/setting-up) +- [カイヤの送受信方法](https://userguide.dcentwallet.com/coin-send-receive/coins/klaytn-klay#how-to-create-an-klay-account) +- [カイア・ウォレットとつながる](https://userguide.dcentwallet.com/external-service/kaikas) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md index a66b1f8d56aa..7ce26ef39375 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md @@ -2,68 +2,68 @@ ![](/img/banners/kaia-safepal.png) -## Introduction +## はじめに -Hardware wallets reinvented the wheel by keeping private keys (needed for signing transactions) in an offline environment separate from internet connections, avoiding the numerous hacks or threats that arise from software wallets reliant on internet connectivity. This way, users' crypto assets are more secured and shielded from internet dangers brought on by software wallets. +ハードウェアウォレットは、インターネット接続から切り離されたオフライン環境に秘密鍵（取引の署名に必要）を保管することで、インターネット接続に依存するソフトウェアウォレットで発生する数々のハッキングや脅威を回避し、車輪を再発明した。 こうすることで、ユーザーの暗号資産はより安全になり、ソフトウェア・ウォレットがもたらすインターネット上の危険から守られる。 -One of such hardware wallets that has integrated with Klaytn is **SafePal S1 Hardware Wallet**. SafePal S1 is a cryptocurrency hardware wallet that aims to provide a secure, simple, and enjoyable crypto management solution for the populace. SafePal is an hardware wallet to secure and manage cryptocurrencies and NFTs, such as Bitcoin, KLAY, Klaytn Compatible Tokens(KCT), Ether and ERC20 tokens e.t.c. +カイアと統合されたハードウェア・ウォレットのひとつが**SafePal S1 Hardware Wallet**である。 SafePal S1は、暗号通貨ハードウェアウォレットで、安全でシンプルで楽しい暗号通貨管理ソリューションを提供することを目的としています。 SafePalは、Bitcoin、KAIA、Kaia Compatible Tokens(KCT)、Ether、ERC20トークンなどの暗号通貨やNFTを安全に管理するハードウェアウォレットです。 -In this guide, you will: +このガイドでは、次のことを説明する： -- Add, Receive and Send Klay, and any Klaytn Compatible Tokens(KCT) with SafePal S1 Hardware Wallet +- SafePal S1ハードウェアウォレットでKlayおよびKaia互換トークン(KCT)を追加、受信、送信できます。 -## Prerequisites +## 前提条件 -- [SafePal Hardware Wallet Set-Up](https://safepalsupport.zendesk.com/hc/en-us/articles/360046051752) +- [SafePal ハードウェアウォレットのセットアップ](https://safepalsupport.zendesk.com/hc/en-us/articles/360046051752) -## Getting Started +## はじめに -After you must have successfully set up your wallet, next is to see the wallet in action. In this tutorial we will be adding, receiving and sending KLAY native coin, and any Klaytn Compatible Tokens(KCT) using the SafePal S1 Hardware Wallet. +ウォレットのセットアップに成功したら、次はウォレットを実際に使ってみましょう。 このチュートリアルでは、SafePal S1ハードウェアウォレットを使用して、KAIAネイティブコインとKaia互換トークン（KCT）の追加、受信、送信を行います。 ### Adding KLAY native coin To add the KLAY native coin to your hardware wallet, kindly follow the steps below: -**Step 1**: Open the SafePal App and in your Wallet tab, click the ellipsis icon and then click the Manage Coins button as shown in the picture below: +**ステップ 1**：SafePalアプリを開き、Walletタブで楕円形のアイコンをクリックし、下図のようにManage Coinsボタンをクリックします： ![](/img/build/tools/step1-add-klay.png) -**Step 2**: Select the coins you want to add (in our case KLAY), and click **Add Coin** at the bottom +**ステップ 2**: 追加したいコイン（私たちの場合はKAIA）を選択し、下部にある**Add Coin**（コインを追加）をクリックします。 ![](/img/build/tools/step2-add-klay.png) -**Step 3**: Scan back and forth between the App and the S1 hardware wallet so that the data is correctly synchronized between the App and the device. +**ステップ3**: アプリとS1ハードウェアウォレットの間でスキャンを繰り返し、データがアプリとデバイス間で正しく同期されるようにします。 -**Step 4**: After the coin has been added successfully, you can now view them in the **Asset Management** tab on the S1 device. +**ステップ4**: コインの追加に成功したら、S1デバイスの**資産管理**タブでコインを確認できます。 ![](/img/build/tools/step4-add-klay.png) -Kindly note that the steps above are applicable for adding any Klaytn Compatible Tokens. +上記の手順は、カイア互換トークンを追加する場合に適用されます。 ### Receiving KLAY native coin -Once the coins (KLAY, KCTs) are successfully added, you can view them in the **Asset Management** tab on the S1 device. You can receive KLAY native coin using the following approach: +コイン（KAIA、KCT）が正常に追加されると、S1デバイスの**資産管理**タブで確認できます。 You can receive KLAY native coin using the following approach: -#### Using the SafePal App +#### SafePal アプリの使用 1. Select KLAY which gives you the option of swap, receive and send, click on receive 2. You can either copy your KLAY address for the wallet, save the QR code, or have the other party scan the QR code from your phone. -#### Using the SafePal S1 Hardware Wallet +#### SafePal S1 ハードウェアウォレットの使用方法 -**Step 1** Start your SafePal S1 device and navigate to the 'Asset Management' +**ステップ 1** SafePal S1 を起動し、「Asset Management（資産管理）」に移動します。 -**Step 2** Select KLAY as the coin you would like to receive from others. +**ステップ2** 他者から受け取りたいコインとしてKAIAを選択します。 -**Step 3** Click on the ‘Receive’ button +**ステップ3** 「受信」ボタンをクリックする。 -**Step 4** Enter the PIN code of your S1 device. +**ステップ4** S1デバイスのPINコードを入力します。 -**Step 5** Then you can see the QR code of your coin address, and show it to others so that they can scan and send the coin to you. +**ステップ5** 次に、あなたのコインの住所のQRコードを見ることができ、それを他の人に見せると、他の人がスキャンしてあなたにコインを送ることができます。 ![](/img/build/tools/sphw-rec-banner.png) -Kindly note that the steps above are applicable for receiving any Klaytn Compatible Tokens. +上記の手順は、カイア互換トークンを受け取る際に適用されます。 ### Sending KLAY native coin @@ -73,35 +73,35 @@ To send KLAY native coin from your hardware wallet, kindly follow the steps belo ![](/img/build/tools/step1-send-klay.png) -**Step 2** Enter the destination address, amount, and click 'Next' to confirm the details again. Ensure to verify your transfer details in this step. +**ステップ2** 宛先住所、金額を入力し、「次へ」をクリックして再度詳細を確認する。 このステップで振込先の詳細を確認してください。 ![](/img/build/tools/step2-send-klay.png) -**Step 3** Initiate the signing process of the S1 device. +**ステップ3** S1デバイスの署名プロセスを開始する。 -In this step, a QR code (as shown below) containing the transfer details will be displayed on the SafePal App. Start your S1 hardware wallet, and enter the **Scan** tab. Next is to scan the QR code on the SafePal App. Doing this ensures that the S1 device receives the transfer details in an offline environment. +このステップでは、送金詳細を含むQRコード（下図）がセーフパルアプリに表示されます。 S1ハードウェアウォレットを起動し、**スキャン**タブに入ります。 次に、SafePalアプリでQRコードをスキャンします。 こうすることで、S1デバイスがオフライン環境で転送の詳細を受信することが保証される。 ![](/img/build/tools/step3-send-klay.png) -**Step 4** Sign the transfer on S1 Device +**ステップ4** S1デバイスで転送に署名する -After successfully scanning the transfer details, you will then see the transfer details(amount, fee, gas limit, etc) on your S1 device. Next is to verify the details and enter the PIN code. +送金明細のスキャンに成功すると、S1デバイスに送金明細（金額、手数料、ガス上限など）が表示されます。 次に詳細を確認し、PINコードを入力する。 ![](/img/build/tools/step4-send-klay.png) -**Step 5** Synchronize the signature back to the SafePal App +**ステップ 5** SafePal アプリに署名を同期します。 -After successfully signing the transfer on the S1 device, you will see a set of dynamic QR codes shown on the S1 device. On the SafePal App, click 'Next' to open the cellphone camera. Use the SafePal App to scan the dynamic QR codes shown on the S1 device. +S1デバイスで転送の署名に成功すると、S1デバイスに一連のダイナミックQRコードが表示されます。 SafePal アプリで「次へ」をクリックし、携帯電話のカメラを開きます。 SafePal アプリを使って、S1 デバイスに表示されるダイナミック QR コードをスキャンします。 -Doing this ensures the App receives the signature contained in the QR codes and is ready to broadcast the transfer to the blockchain (Klaytn). +こうすることで、アプリはQRコードに含まれる署名を確実に受け取り、ブロックチェーン（Kaia）への転送をブロードキャストする準備が整う。 -**Step 6** Click **Broadcast** on the App and wait for the transfer to go through +**ステップ6** アプリで**ブロードキャスト**をクリックし、転送が完了するのを待ちます。 ![](/img/build/tools/step6-send-klay.png) -Kindly note that the steps above are applicable for sending any Klaytn Compatible Tokens. +上記の手順は、カイア互換トークンを送信する際に適用されます。 -## Further References +## 参考文献 -- [SafePal S1 Upgrade Instructions](https://www.safepal.com/en/upgrade/s1) -- [SafePal S1 User Manual](https://docs.safepal.io/safepal-hardware-wallet/user-manual) +- [SafePal S1 アップグレード手順](https://www.safepal.com/en/upgrade/s1) +- [SafePal S1 ユーザーマニュアル](https://docs.safepal.io/safepal-hardware-wallet/user-manual) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md index 33be7a32a031..da04d6d81f8b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md @@ -1,27 +1,27 @@ -# Interact with Contracts +# 契約との対話 -In this section, you will be interacting with and sending a transaction to a simple contract deployed on Kairos using our newly created multisig wallet. +このセクションでは、新しく作成したマルチシグウォレットを使って、Kairos上にデプロイされたシンプルなコントラクトとやり取りし、トランザクションを送信します。 -**Pre-requisites** +**前提条件** -- [Metamask](https://metamask.io/download/) & [Kaia Metamask Config](../../../tutorials/connecting-metamask.mdx#send-klay) +- [メタマスク](https://metamask.io/download/) & [カイアメタマスクコンフィグ](../../../tutorials/connecting-metamask.mdx#send-klay) - [Remix](https://remix.ethereum.org/) & [Kaia Remix Plugin](https://klaytn.foundation/using-klaytn-plugin-on-remix/) -- Obtain test KAIA from the [Faucet](https://faucet.kaia.io) +- [Faucet](https://faucet.kaia.io)からテスト用KAIAを入手。 -**Step 1:** Navigate to [Remix](https://remix.ethereum.org/) +**ステップ1:** [Remix](https://remix.ethereum.org/)に移動します。 -**Step 2:** Compile and deploy the sample **storage contract**. +**ステップ2：** サンプルの**storage contract**をコンパイルし、デプロイする。 -The contract must first be deployed before you may interact with it in your multisig wallet. This sample contract contains a simple uint "number" variable that can be updated by calling the **store** method and retrieved by calling the **retrieve** method. +マルチシグウォレットでコントラクトを使用する前に、まずコントラクトをデプロイする必要があります。 このサンプル・コントラクトには、**store** メソッドを呼び出すと更新され、**retrieve** メソッドを呼び出すと取得される、単純な uint "number" 変数が含まれています。 ![](/img/build/tools/kaia-safe/ks-ic-deploy.gif) -**Step 3:** Initiate a new transaction. +\*\*ステップ3：\*\*新規取引を開始する。 -To interact with a smart contract in your safe wallet, click **"New Transaction"**. To complete this step, you will need your already deployed contract address and ABI, as illustrated in the previous step. +安全なウォレットでスマート・コントラクトとやり取りするには、\*\*"New Transaction "\*\*をクリックします。 このステップを完了するには、前のステップで説明したように、すでにデプロイされている契約アドレスとABIが必要です。 ![](/img/build/tools/kaia-safe/kaia-safe-ci-init.gif) -**Step 4:** Review and submit the transaction. You will need to sign the transaction with your signer wallet, and it will be executed once the confirmation threshold is reached. +**ステップ4：** 取引を確認し、提出する。 取引は署名者ウォレットで署名する必要があり、確認のしきい値に達すると実行されます。 ![](/img/build/tools/kaia-safe/kaia-safe-ci-review-send.gif) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/csv-airdrop.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/csv-airdrop.md new file mode 100644 index 000000000000..4ad44b0b381e --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/csv-airdrop.md @@ -0,0 +1,70 @@ +# CSVエアドロップを使用する + +これはKaia Safeのカスタムアプリで、ERC20、ERC721、ERC1155、ネイティブトークンの複数の送金を一括して1つのトランザクションにすることができます。 CSV転送ファイルを1つアップロード／コピー＆ペーストし、送信ボタンを押すだけという簡単さです。 + +この方法一つで、署名やトランザクションが少なくて済むため、ガス⛽と相当な時間⌚を節約できる。 + +それでは、CSV Airdropを使った例を見てみよう！ + +## ステップ1: [カイアセーフ](https://safe.kaia.io/)にログインします。 + +セーフのアカウントをまだ作成していない場合は、[セーフの作成ガイド](./use-kaia-safe.md#create-a-safe)および[資産の追加ガイド](./use-kaia-safe.md#add-assets)を参照して、アカウントを設定し、資産 (KAIA、FT、NFT) を追加してください。 + +## ステップ2：アプリをクリックし、CSVを検索し、CSV Airdropを選択します。 + +![](/img/build/tools/kaia-safe/search-csv-app.png) + +## ステップ3：転送用CSVファイルの準備 + +転送ファイルは、以下の必須カラムを含むCSV形式であることが期待される： + +- _token_type_：転送されるトークンのタイプ。 erc20、nft、ネイティブのいずれか。 NFT トークンは ERC721 または ERC1155 のいずれかとなります。 +- _token_address_：転送する ERC20 トークンのイーサリアムアドレス。 ネイティブ(ETH)送金の場合、これは空白のままにしておかなければならない。 +- _receiver_：送金先のイーサリアムアドレス。 +- _amount_：転送するトークンの量。 erk721転送の場合は空白のままでよい。 +- _id_：転送する収集可能トークン (erc721 または erc1155) の ID。 ネイティブおよびerk20の移籍では空白のままでよい。 + +:::important +CSVファイルは、", "をセパレーターとして使用し、ヘッダー行は常に最初の行として提供され、記述されたカラム名を含まなければならない。 +[サンプル転送ファイル](https://ipfs.io/ipfs/bafybeiesr6b3cm76ofcm2joukgdtuyva3niftmbpbb4sgxsa3qwsenv3lu/sample.csv) +::: + +### ネイティブ・トークン・トランスファー + +ネイティブ・トークンはトークン・アドレスを持たないため、ネイティブ転送では _token_address_ 列を空白にする必要があります。 + +![](/img/build/tools/kaia-safe/native-csv-app.png) + +:::note +kaiaセーフウォレットのアドレスに十分なネイティブトークンがあることを確認してください。 +::: + +### ERC-20 移籍 + +erc20 の転送には _token_type_ として erc20 を指定し、その他のフィールドもそれに合わせて指定する。 + +![](/img/build/tools/kaia-safe/erc20-csv-app.png) + +:::note +kaia セーフウォレットのアドレスに十分な erc20 トークンがあることを確認してください。 +::: + +### ERC-721 移籍 + +erc721 転送のために _token_type_ として erc721 を提供し、それに応じて他の各フィールドも提供する。 + +![](/img/build/tools/kaia-safe/erc721-csv-app.png) + +:::note +kaia セーフウォレットのアドレスに十分な erc721 トークンがあることを確認してください。 +::: + +### イラスト + +この例では、2つのネイティブ転送、2つのERC20転送、1つのERC721転送がある。 + +![](/img/build/tools/kaia-safe/rs-csv-app.png) + +## ステップ 4: 取引の確認と提出 + +取引内容を確認することができます。 準備ができたら、Submit をクリックして、他の Safe トランザクションと同様にトランザクションを実行します。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md index d41463298cd6..0d30fdd2be5b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md @@ -1,106 +1,106 @@ # Frequently Asked Questions -## Can I add new owners after creating a safe? +## 金庫を作成した後、新しい所有者を追加できますか？ -Yes! After creating your safe account, Kaia Safe gives you access to manage safe owners, i.e., add, remove, and replace owners, or rename existing owners. +そうだ！ 金庫のアカウントを作成した後、Kaia Safeは金庫の所有者を管理する、つまり所有者を追加、削除、交換、または既存の所有者の名前を変更するアクセス権を提供します。 -Note: To execute this change, you need to be connected with one of the current owners. +注：この変更を実行するには、現在のオーナーのひとりとつながっている必要があります。 -The steps below explain how to add new owners or signers to your Safe account after its creation. +以下の手順では、Safe アカウントの作成後に新しい所有者や署名者を追加する方法を説明します。 -**Step 1:** Go to **Settings** in the sidebar menu, you ll see the **Manage Safe Account signers** card under the **Setup** section. +**ステップ1:** サイドバーメニューの**Settings**に移動すると、**Setup**セクションの下に**Manage Safe Account Signers**カードが表示されます。 -**Step 2:** Click the **Add new signer** button at the bottom of the card. Clicking this button would open a new window. +\*\*ステップ 2: \*\* カード下部の **Add new signer** ボタンをクリックします。 このボタンをクリックすると、新しいウィンドウが開く。 ![](/img/build/tools/kaia-safe/ks-add-signers.png) -**Step 3:** Enter the **name** of the new owner and paste the **owner's address**. Then click the next button at the bottom-right of the page. +**ステップ3：**新しい所有者の**名前**を入力し、**所有者の住所**を貼り付けます。 次にページ右下の「次へ」ボタンをクリックする。 -**Step 4:** Set a new signature policy. In this case, you can either change or retain the existing signature policy. The image below shows that 2 out of the 4 owners are required to confirm and execute any transaction. +**ステップ4:** 新しい署名ポリシーを設定します。 この場合、既存の署名ポリシーを変更するか、保持するかのいずれかを選択することができます。 下の画像は、4人の所有者のうち2人が取引の確認と実行を要求されていることを示している。 ![](/img/build/tools/kaia-safe/ks-add-signer-details.png) -**Step 5:** Review and submit the transaction. +**ステップ5：** 取引を確認し、提出する。 -Confirm that all changes are correct before submitting. You can therefore submit the change by clicking on the **submit** button. +提出する前に、すべての変更が正しいことを確認してください。 そのため、**submit**ボタンをクリックして変更を提出することができます。 -After clicking on **Submit**, your connected wallet will ask you to confirm the change. Depending on your existing signature policy, other owners will have to confirm the change just like a regular transaction. +**Submit**をクリックすると、接続されているウォレットが変更を確認するよう求めます。 既存の署名ポリシーにもよるが、他のオーナーは通常の取引と同様に変更を確認する必要がある。 ![](/img/build/tools/kaia-safe/kaia-safe-change-owner-setup-review.gif) -## Can I change the number of required signer confirmation? +## 必要な署名者確認数を変更することはできますか？ -Yes! You can change the number of signer confirmations required by following the steps to be shown below. This is important because you might want to change the owners or signers required to confirm transactions associated with your safe account. +そうだ！ 以下に示す手順に従い、署名者確認の必要回数を変更することができる。 これは、金庫口座に関連する取引の確認に必要な所有者や署名者を変更したい場合があるため、重要です。 -**Step 1:** Go to **Settings** in the sidebar menu, you ll see the **Required Confirmation** card under the **Setup** section. +**ステップ1:**サイドバーメニューの**設定**に移動すると、**設定**セクションの下に**必要な確認**カードが表示されます。 -This shows your current signature policy, and from the image below, 2 out of 4 owners are required to confirm any transaction. +これは現在の署名方針を示しており、下の画像から、4人の所有者のうち2人が取引を確認する必要があります。 ![](/img/build/tools/kaia-safe/ks-conf-policy.png) -**Step 2:** Click on the **change** button. +\*\*ステップ2:**変更**ボタンをクリックしてください。 -This pops up a new window to select your new signature threshold. +新しい署名のしきい値を選択するための新しいウィンドウがポップアップ表示されます。 ![](/img/build/tools/kaia-safe/ks-conf-policy-btn.png) -**Step 3:** Click on the **Submit** button. +**ステップ3：**「送信」ボタンをクリックしてください。 -Note that depending on your existing signature policy, other owners will have to confirm the change just like a regular transaction. +既存の署名ポリシーによっては、他のオーナーが通常の取引と同様に変更を確認する必要があることに注意してください。 -## How do I add an existing safe? +## 既存の金庫を追加するには？ -Using your exported Safe data, which contains your added Safe accounts, address book, and settings, you can easily add your Safe account. +エクスポートした Safe データには、追加した Safe アカウント、アドレス帳、および設定が含まれています。 -> Note: You must have downloaded your Safe data as shown in the image below: +> 注: 以下の画像に示すように、セーフ データをダウンロードしている必要があります： ![](/img/build/tools/kaia-safe/ks-export-btn.png) -The need to add or load an existing safe into the interface varies. These may include: +既存の金庫をインターフェイスに追加したり、ロードしたりする必要性は様々である。 これには以下が含まれる： -- You want to access your Safe from a different browser. -- You want to interact with Safe where another party made you an owner. -- You want to add any existing safe in read-only mode. +- 別のブラウザからセーフにアクセスしたい。 +- 他人がオーナーにしたSafeと交流したい。 +- 既存の金庫を読み取り専用モードで追加したい。 -Let's go through the process of adding your existing safe in the following steps. Note: Please ensure that your signer's wallet is connected. +以下のステップで既存の金庫を追加していきましょう。 注：署名者のウォレットが接続されていることを確認してください。 -**Step 1:** Navigate to **Settings** tab. +\*\*ステップ1: **設定**タブに移動します。 -**Step 2:** Scroll to the **Data Import** card under the **Data** section. +**ステップ2:** **データ**セクションの下にある**データインポート**カードまでスクロールしてください。 ![](/img/build/tools/kaia-safe/ks-data-import-i.png) -Here you can either Drag and Drop a JSON file or choose your file as seen in the image above. +ここでは、JSONファイルをドラッグ・アンド・ドロップするか、上の画像のようにファイルを選択することができます。 -**Step 3:** Click on **Import** button. +\*\*ステップ3：**インポート**ボタンをクリックしてください。 ![](/img/build/tools/kaia-safe/ks-data-import-btn.png) ![](/img/build/tools/kaia-safe/kaia-safe-data-import.gif) -After this, you should now have access to your Safe account. +これで、セーフアカウントにアクセスできるようになります。 -## Common safe Set-up +## 一般的な金庫の設定 -This tends to provide some pointers regarding decisions to take when setting up a Safe. These may include: +これは、セーフを設定する際に取るべき決断に関するいくつかのヒントを提供する傾向がある。 これには以下が含まれる： -- How many owners? +- オーナーは何人ですか？ -- What threshold? +- 閾値とは？ -- What wallets are compatible? +- 互換性のある財布は？ -There is no one best response to these three questions, therefore there is no one optimum Safe configuration. Really, it all depends on the particular use case. Nevertheless, we make an effort to offer some suggestions for things to take into account: +これら3つの質問に対する最適な回答は1つではないため、最適なセーフ・コンフィギュレーションは存在しない。 本当に、すべては特定のユースケースによる。 とはいえ、考慮すべき点をいくつか提案できるよう努力はしている： -**How many owners?** +**オーナーは何人？** -Typically, having many owner accounts is a smart option. It is good practice for several people to have access to the safe account when groups are managing funds. It is advised for individuals who manage money to have multiple accounts so they can use more than one authentication factor. +通常、多くのオーナー口座を持つことは賢い選択である。 グループで資金を管理する場合は、複数の人が金庫の口座にアクセスできるようにするのがよい習慣です。 お金を管理する個人は、複数の認証要素を使用できるように、複数の口座を持つことをお勧めします。 -**What threshold?** +**閾値とは？** -A Safe's threshold is the minimum number of owner accounts that must approve a transaction before it can be successfully executed. It is advisable to use a threshold greater than 1, ensuring that at least one additional account is always needed to validate and carry out Safe transactions, rather than allowing a single account to carry out transactions. As a result, money cannot be moved even if an attacker gains access to one account. +セーフのしきい値とは、トランザクションが正常に実行されるまでに承認されなければならない所有者アカウントの最小数である。 1より大きい閾値を使用することが望ましく、1つのアカウントで取引を実行するのではなく、安全な取引を検証し実行するために、少なくとも1つの追加アカウントが常に必要となるようにする。 その結果、攻撃者が1つの口座にアクセスしたとしても、資金を移動させることはできない。 -Additionally, it is recommended to choose a threshold of 51% of the total owners, e.g., 2 out of 3, 3 out of 5, etc. Because of this, even if one owner loses access to their account, users are not immediately locked out of all of their money in the Safe; instead, the other owners can still perform transactions and, for example, replace that lost owner account. One can contend that this serves as a recovery mechanism. +さらに、所有者総数の 51%を閾値とすることを推奨する。例えば、3 人中 2 人、5 人中 3 人など。 このため、所有者の一人がアカウントへのアクセスを失っても、利用者は金庫内のすべての資金から即座にロックアウトされることはなく、他の所有者が取引を実行し、たとえば、その失われた所有者のアカウントを交換することができます。 これはリカバリーメカニズムとして機能していると言える。 -**What wallets are compatible?** -At the moment, Kaia Safe is compatible with [Kaia Wallet](https://docs.kaiawallet.io/), [MetaMask](../../../tutorials/connecting-metamask.mdx). +**対応しているウォレットは？** +現時点では、Kaia Safeは[Kaia Wallet](https://docs.kaiawallet.io/)と[MetaMask](../../../tutorials/connecting-metamask.mdx)に対応しています。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md index b21b9e6672d6..e1f805bab53c 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md @@ -1,46 +1,46 @@ --- id: kaia-safe-api-kit -title: Kaia Safe API-Kit +title: カイアセーフAPI-Kit --- import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -# Kaia Safe API Kit +# カイア安全APIキット -API-Kit is your go-to kit for securely interacting with the [Safe Transaction API](https://github.com/safe-global/safe-transaction-service). The core of this kit is to allow valid signers to propose and share transactions with the other signers of a Safe, send the signatures to the service to collect them, and get information about a Safe (like reading the transaction history, pending transactions, enabled Modules and Guards, etc.), among other features. +API-Kitは、[Safe Transaction API](https://github.com/safe-global/safe-transaction-service)と安全にやり取りするためのキットです。 このキットの中核は、有効な署名者が Safe の他の署名者に取引を提案・共有したり、署名を収集するサービスに署名を送信したり、Safe に関する情報（取引履歴、保留中の取引、有効なモジュールやガードなど）を取得したりできるようにすることである。 -## Quickstart +## クイックスタート -By the end of this guide, you will be able to propose transactions to the service and obtain the owners' signatures for execution. +このガイドを読み終える頃には、同サービスに取引を提案し、実行のためにオーナーの署名を得ることができるようになるだろう。 -## Prerequisites +## 前提条件 -1. [Node.js and npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) -2. A Safe with several signers +1. [Node.js と npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) +2. 複数の署名者がいる金庫 -## Set up environment +## 環境設定 -### Step 1: Create a project directory. +### ステップ1：プロジェクト・ディレクトリを作成する。 -Copy and paste this command in your terminal to create the project folder. +このコマンドをコピーしてターミナルに貼り付け、プロジェクトフォルダを作成する。 ```js mkdir kaiasafe-api-kit cd kaiasafe-api-kit ``` -### Step 2: Initialize an npm project. +### ステップ2： npmプロジェクトを初期化する。 -Copy and paste this command in your terminal to create a `package.json` file. +このコマンドをターミナルにコピー＆ペーストして、`package.json`ファイルを作成する。 ```js npm init -y ``` -### Step 3: Install dependencies. +### ステップ3：依存関係をインストールする。 -Using API-Kit is as simple as running the installation command below: +API-Kitの使用方法は、以下のインストールコマンドを実行するだけです： @@ -56,11 +56,11 @@ Using API-Kit is as simple as running the installation command below: -### Step 4: Import dependencies. +### ステップ4：依存関係をインポートする。 -Create a file named `app.js`. This is where all our code snippets for this interaction would live. +`app.js`という名前のファイルを作成する。 このインタラクションのためのコード・スニペットはすべてここにある。 -Copy and paste these necessary imports at the top of the `app.js` file. +これらの必要なインポートをコピーして、`app.js`ファイルの先頭に貼り付ける。 ```js import SafeApiKit from '@safe-global/api-kit' @@ -70,11 +70,11 @@ import { } from '@safe-global/safe-core-sdk-types' ``` -### Step 5: Configure Setup +### ステップ5：セットアップの設定 -To efficiently illustrate how API-Kit works, we will use a Safe account setup with two or more signers, and threshold two, so we have multiple signatures that need to be collected when executing a transaction. +API-Kitがどのように機能するかを効率的に説明するために、2人以上の署名者を持つSafeアカウントのセットアップを使用する。 -Copy and paste the following under the import statements in your `app.js` file: +以下をコピーして、`app.js`ファイルのimport文の下に貼り付ける： ```js // https://chainlist.org/?search=kaia&testnets=true @@ -86,13 +86,13 @@ const OWNER_2_PRIVATE_KEY = ""; // OWNER const TO_ADDRESS = OWNER_1_ADDRESS; // Receiver address of sample transaction who receives 1 wei ``` -## Use API Kit +## APIキットを使用する -### Step 1: Initialize API Kit +### ステップ1：APIキットの初期化 -To initialize API Kit, we need to create an instance of the API Kit. +API Kitを初期化するには、API Kitのインスタンスを作成する必要がある。 -> In chains where the [Safe Transaction Service](https://docs.safe.global/core-api/transaction-service-overview) is supported, it's enough to specify the chainId property. +> Safe Transaction Service](https://docs.safe.global/core-api/transaction-service-overview) がサポートされているチェーンでは、chainId プロパティを指定するだけで十分です。 ```js const apiKit = new SafeApiKit.default({ @@ -102,11 +102,11 @@ const apiKit = new SafeApiKit.default({ ``` -As you can see above, we included custom service using the optional **txServiceUrl** property. +上で見たように、オプションの**txServiceUrl**プロパティを使用してカスタムサービスを含めました。 -### Step 2: Initialize Protocol Kit +### ステップ2：プロトコルキットの初期化 -To handle transactions and signatures, we need to create an instance of the Protocol Kit (a kit that enables developers to interact with [Safe Smart Accounts](https://github.com/safe-global/safe-smart-account) using a TypeScript interface) with the provider, signer and safeAddress. +トランザクションと署名を処理するには、プロバイダ、署名者、safeAddressを指定して、Protocol Kit（開発者がTypeScriptインタフェースを使用して[Safe Smart Accounts](https://github.com/safe-global/safe-smart-account)とやり取りできるようにするためのキット）のインスタンスを作成する必要がある。 ```js const protocolKitOwner1 = await Safe.default.init({ @@ -116,9 +116,9 @@ const protocolKitOwner1 = await Safe.default.init({ }) ``` -### Step 3: Propose a transaction to the service +### ステップ3：サービスにトランザクションを提案する -One of the core features of API Kit is to enable valid signers to share transactions with other signers. But before this is done, any of the Safe signers needs to initiate the process by creating a proposal of a transaction. This transaction is then sent to the service to make it accessible by the other owners so they can give their approval and sign the transaction as well. +API Kitの中核機能の1つは、有効な署名者が他の署名者とトランザクションを共有できるようにすることである。 しかし、その前に、セーフサイナーの誰かが取引のプロポーザルを作成し、プロセスを開始する必要がある。 この取引は、他の所有者がアクセスできるようにするためにサービスに送信され、他の所有者も同様に承認を与え、取引に署名することができる。 ```js const safeTransactionData = { @@ -146,9 +146,9 @@ try { } ``` -### Step 4: Retrieve pending transaction +### ステップ4：保留中のトランザクションを取得する -API Kit provides us different methods to retrieve pending transactions depending on the situation. For this guide, we will retrieve a transaction given the Safe transaction hash and other available methods commented out below: +API Kitは、状況に応じて保留中のトランザクションを取得するためのさまざまな方法を提供してくれる。 このガイドでは、セーフトランザクションハッシュと以下に示すその他の利用可能なメソッドを使用してトランザクショ ンを取得する： ```js const transaction = await apiKit.getTransaction(safeTxHash) @@ -159,9 +159,9 @@ const transaction = await apiKit.getTransaction(safeTxHash) // const transactions = await service.getAllTransactions() ``` -## Step 5: Confirm the transaction +## ステップ5：取引の確認 -The next thing to do is to sign the transaction with the Protocol Kit and submit the signature to the Safe Transaction Service using the [confirmTransaction](https://docs.safe.global/sdk/api-kit/reference#confirmtransaction) method. +次に行うことは、プロトコルキットを使用してトランザクションに署名し、[confirmTransaction](https://docs.safe.global/sdk/api-kit/reference#confirmtransaction) メソッドを使用して署名を Safe Transaction Service に提出することである。 ```js const protocolKitOwner2 = await Safe.default.init({ @@ -177,11 +177,11 @@ const signatureResponse = await apiKit.confirmTransaction( ) ``` -### Step 6: Execute the transaction +### ステップ6：トランザクションの実行 -The Safe transaction is now ready to be executed. This can be done using the [Safe Wallet Web](https://app.safe.global/) interface, the [Protocol Kit](https://docs.safe.global/sdk/protocol-kit#execute-the-transaction), the Safe CLI or any other tool that's available. +これで Safe トランザクションを実行する準備ができた。 これは、[Safe Wallet Web](https://app.safe.global/)インターフェース、[Protocol Kit](https://docs.safe.global/sdk/protocol-kit#execute-the-transaction)、Safe CLI、または利用可能なその他のツールを使用して行うことができます。 -For this last step, we executed the safe transaction using Protocol Kit. +この最後のステップでは、Protocol Kitを使って安全なトランザクションを実行した。 ```js const safeTxn = await apiKit.getTransaction(safeTxHash); @@ -191,7 +191,7 @@ console.log('Transaction executed:'); console.log(`https://kairos.kaiascan.io/tx/${hash}`) ``` -At the end, the full code in `app.js` should look like this: +最後に、`app.js`の完全なコードは次のようになるはずだ： ```js import SafeApiKit from '@safe-global/api-kit' @@ -267,4 +267,4 @@ console.log('Transaction executed:'); console.log(`https://kairos.kaiascan.io/tx/${hash}`) ``` -Visit the [API Kit Reference](https://docs.safe.global/sdk/api-kit/reference) for more information, and navigate to [Github](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/snippets) to access the full source code for this guide. +詳細については、[API Kit Reference](https://docs.safe.global/sdk/api-kit/reference)をご覧ください。また、このガイドの全ソースコードにアクセスするには、[Github](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/snippets)に移動してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md index c9668bdfeaeb..92fbd592ee67 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md @@ -1,37 +1,37 @@ # Kaia Safe -In a typical blockchain platform like Kaia, most users are familiar with single key wallet systems such as Kaia Wallet and MetaMask, which are also known as externally owned accounts (EOA). These accounts make use of traditional key pairs, i.e., public keys and private keys, which isn’t ideal as the private key creates a single point of failure. +カイアのような典型的なブロックチェーンプラットフォームでは、ほとんどのユーザーはカイアウォレットやメタマスクのようなシングルキーのウォレットシステムに精通しており、これらは外部所有アカウント（EOA）としても知られている。 これらのアカウントは、従来の鍵ペア、つまり公開鍵と秘密鍵を使用しているが、秘密鍵が単一障害点を生み出すため、理想的とは言えない。 -This makes EOAs unsuitable for organisational use, as a compromised private key could lead to the organisation losing all of its crypto funds—such was the case in the [Wintermute hack](https://www.certik.com/resources/blog/uGiY0j3hwOzQOMcDPGoz9-wintermute-hack-) where $162.5 million was lost. +このため、EOAは組織的な利用には不向きである。秘密鍵が漏洩した場合、組織が保有する暗号資金のすべてを失う可能性があるからだ。[Wintermute hack](https://www.certik.com/resources/blog/uGiY0j3hwOzQOMcDPGoz9-wintermute-hack-)では、1億6250万ドルが失われた。 -This is where multisig wallets like Kaia Safe come in. Unlike single key wallets, a multi-sig wallet needs multiple parties' private keys to sign and execute a transaction, removing the single point of failure and providing greater security for organisational use cases. +そこで、Kaia Safeのようなマルチシグ・ウォレットの出番となる。 シングルキーウォレットとは異なり、マルチシグウォレットは、トランザクションに署名し実行するために複数の当事者の秘密鍵が必要である。 -## What are MultiSig Wallets? +## マルチシグ財布とは？ -As the name implies, a multi-signature wallet is a digital wallet that requires two, three, or more private keys from different sources to confirm and execute a crypto transaction. +その名の通り、マルチシグネチャ・ウォレットは、暗号トランザクションを確認し実行するために、異なるソースからの2つ、3つ、またはそれ以上の秘密鍵を必要とするデジタル・ウォレットである。 -For example, you can imagine a multi-signature wallet as a safe that has three locks. The three keys required to open the safe are with three different individuals, thus requiring their joint consent to open. +例えば、マルチシグネチャーの財布は、3つの鍵がある金庫のようなものだと想像できる。 金庫を開けるのに必要な3つの鍵は、3人の異なる個人が所有しているため、開けるには彼らの共同同意が必要である。 -Here are the main benefits of multisig wallets: +マルチシグウォレットの主な利点は以下の通りです： -- **Store assets/funds securely:** Companies and protocols can store their funds safely without worrying about a private key leak or one bad actor moving funds without authorization. +- \*\*資産/資金を安全に保管する：\*\*企業やプロトコルは、秘密鍵の漏洩や、悪意のある人物が承認なしに資金を移動させることを心配することなく、資金を安全に保管することができます。 -- **Enable decentralised decision making:** Companies and business executives can make on-chain decisions on which transactions to execute. +- **分散型の意思決定を可能にする:** 企業や企業幹部は、どの取引を実行するかについてオンチェーンで意思決定を行うことができる。 -- **Two-factor authentication:** With the help of multisig wallets, businesses and individuals can make sure that only those with access to the necessary keys can execute transactions. +- **二要素認証：** マルチシグ・ウォレットを使えば、企業や個人は必要な鍵にアクセスできる者だけが取引を実行できるようにすることができる。 -Next, we will dive into Kaia Safe, a multisig wallet for Klatyn, and how to use it to manage your funds and transactions. +次に、Klatyn用のマルチシグウォレットであるKaia Safeについて説明し、資金と取引を管理するためにKaia Safeを使用する方法について説明する。 -## What is Kaia Safe? +## カイア・セーフとは？ -Kaia Safe is a multisig wallet for the Kaia ecosystem. It is a fork of the well-known multisig wallet [Gnosis Safe](https://gnosis-safe.io/). +Kaia SafeはKaiaエコシステム用のマルチシグウォレットです。 有名なマルチシグウォレット[Gnosis Safe](https://gnosis-safe.io/)のフォークである。 -## Benefits +## メリット -- **Store and transfer KAIA and KCTs (KIP7, KIP17)**: Users can deposit and transfer cryptocurrencies (KAIA) and tokens (fungible or non-fungible). +- **KAIAとKCT（KIP7、KIP17）の保管と送金**：ユーザーは暗号通貨(KAIA)とトークン(fungibleまたはnon-fungible)を預け入れ、送金することができます。 -- **Flexibility and security:** The confirmation threshold gives users more flexibility and control over which transactions should be executed, and removes the single point of failure. +- \*\*柔軟性とセキュリティ：\*\*確認しきい値は、どのトランザクションを実行すべきかについて、ユーザーに柔軟性とコントロールを与え、単一障害点を取り除く。 -- **Safe apps:** Kaia Safe's functionality is expanded by the addition of custom apps that enable batch transactions and interaction with other dApps. One example of this safe app is the **Transaction Builder** which combines and executes multiple transactions as a batch transaction. +- **Safe apps:** Kaia Safeの機能は、バッチ処理や他のdAppsとのインタラクションを可能にするカスタムアプリの追加によって拡張されます。 この安全なアプリの一例が、複数のトランザクションをバッチ・トランザクションとして結合して実行する**トランザクション・ビルダー**である。 -- **Account recovery:** In the event of lost keys, Kaia Safe accounts can be recovered as long as the confirmation threshold can still be met by the remaining keys. +- **アカウント復旧：** 鍵を紛失した場合、残っている鍵で確認しきい値を満たす限り、Kaia Safe のアカウントは復旧できます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md index ad7cbed007c7..7255dc04c3cc 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md @@ -1,15 +1,16 @@ -# Kaia Safe Design +# カイア・セーフ・デザイン -Currently, Kaia Safe is a collection of tools to create and manage multi-signature wallets, viz: +現在、Kaia Safeはマルチシグネチャ・ウォレットを作成・管理するためのツール群である： -- **Safe React:** This is a react web app to create and interact with a multi-sig wallet. +- **Safe React:** これは、マルチシグ・ウォレットを作成し、それとやり取りするためのリアクト・ウェブ・アプリである。 -- **Safe Transaction Service:** This keeps track of transactions sent via safe contracts and listens to events from recent blocks in Mainnet and Kairos. Transactions can also be sent to the service to allow off-chain collecting of signatures or to inform the owners about a transaction that is pending to be sent to the blockchain. +- **Safe Transaction Service:** これは、セーフコントラクト経由で送信されたトランザクションを追跡し、メインネットとカイロスの最近のブロックからのイベントを監視します。 また、オフチェーンで署名を集めたり、ブロックチェーンへの送信が保留されている取引について所有者に通知したりするために、取引をサービスに送信することもできる。 -- **Safe Config Service:** This provides configuration information of the Kaia Safe clients environment, e.g configs of all chain details and APIs. +- **Safe Config Service:** これは、Kaia Safe クライアント環境の設定情報を提供します。例えば、チェーンの詳細や API の設定などです。 -- **Safe Client Gateway:** This is a gateway between the Kaia Safe client and the backend services (transaction service and Kaia Nodes) +- \*\*Safe Client Gateway：\*\*これは、Kaia Safeクライアントとバックエンドサービス（トランザクションサービスおよびKaia Nodes）間のゲートウェイです + 。 -- **Safe Infrastructure:** This is a cluster setup to deploy the backend services (Safe-Transaction, Safe-Config, Safe-Client gateway). +- **Safe Infrastructure:** バックエンドサービス（Safe-Transaction、Safe-Config、Safe-Client Gateway）をデプロイするためのクラスタセットアップです。 -Please refer to this [link](https://github.com/kaiachain/kaia-safe-infrastructure) to get more information. +詳しくはこちらの[リンク](https://github.com/kaiachain/kaia-safe-infrastructure)をご参照ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md index 233a4d6194d6..3cb97962011c 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md @@ -1,77 +1,77 @@ -# Use Transaction Builder +# トランザクション・ビルダーを使用する -This is a custom app in Kaia Safe that is responsible for batching transactions. This means that we you can bundle several transactions together, instead of having to confirm one transaction after the other. You just have to confirm and execute once. +これはKaia Safeのカスタムアプリで、トランザクションのバッチ処理を行う。 つまり、トランザクションを1つずつ確認するのではなく、複数のトランザクションをまとめて確認することができるのです。 一度確認して実行するだけでいい。 -With transaction builder, you can compose transactions from token transfers to complex contract interactions and batch them into a single transaction. +トランザクションビルダーを使えば、トークンの移転から複雑なコントラクトのやり取りまで、トランザクションを組み合わせて1つのトランザクションにまとめることができる。 ## KLAY Token Transfer -You can perform token transfer using transaction builder by following the steps below: +以下の手順で、トランザクションビルダーを使用してトークン転送を行うことができます： -**Step 1:** Navigate to Safe Apps and open Transaction Builder Safe App +**ステップ 1:** Safe Apps に移動し、Transaction Builder Safe App を開きます。 ![](/img/build/tools/kaia-safe/ks-tx-builder.png) -**Step 2:** Enter the recipient wallet address. For this guide, kindly skip the ABI field as we are trying to execute KLAY transfer transaction. +**ステップ2:** 受取人のウォレットアドレスを入力します。 For this guide, kindly skip the ABI field as we are trying to execute KLAY transfer transaction. ![](/img/build/tools/kaia-safe/tx-builder-token-recipient-addr.png) -**Step 3:** Enter the KLAY value you want to send. +**ステップ3：** 送信したいKAIA値を入力してください。 -> Note: In this guide, we are sending 1 KLAY, so we entered 1 in the **KLAY value** input field. You can input any amount here, depending on your Safe's KLAY balance. +> 注：このガイドでは、1つのKAIAを送信するので、**KAIA値**入力フィールドに1を入力した。 You can input any amount here, depending on your Safe's KLAY balance. ![](/img/build/tools/kaia-safe/tx-builder-token-trf-value.png) -**Step 4:** Click Add transaction. +\*\*ステップ4： \*\*トランザクションの追加をクリックします。 -**Step 5:** Repeat steps 2, 3, and 4 for every recipient address. +**ステップ5:** すべての受信者アドレスについて、ステップ2、3、4を繰り返します。 -**Step 6:** Once you added all operations to the batch click Create Batch. +**ステップ6：** バッチにすべての操作を追加したら、[Create Batch]をクリックします。 ![](/img/build/tools/kaia-safe/token-trf-tx-builder.gif) -**Step 7:** Review and submit transaction +**ステップ 7：** 取引の確認と提出 -You'll be able to review the whole batch. Once ready, click Send Batch to submit and execute the transaction just like any other Safe transaction. +全バッチを見直すことができるようになる。 準備ができたら、「Send Batch（バッチ送信）」をクリックして、他の Safe 取引と同様に取引を送信し、実行します。 -## Contract Interactions +## 契約の相互作用 -Let's say you want to airdrop tokens to a long list of addresses, say 10 CCT tokens to 5 addresses. Instead of having to create 5 transactions, which the owners of your safe have to confirm and execute one after the other, the transaction builder puts all these transfers into a single transaction. +例えば、5つのアドレスに10CCTトークンというように、長いアドレスリストにトークンをエアドロップしたいとします。 5つのトランザクションを作成し、それを金庫の所有者が次々に確認・実行する代わりに、トランザクション・ビルダーはこれらの送金をすべて1つのトランザクションにまとめる。 -In this guide, we have minted CCT tokens to the Safe address for illustrative purpose. +このガイドでは、説明のためにCCTトークンをSafeアドレスに鋳造しています。 -Let’s get started with this example using Transaction Builder! +それでは、Transaction Builderを使ってこの例を始めてみよう！ -**Step 1:** Open Safe Apps. +\*\*Safe Apps を開きます。 ![](/img/build/tools/kaia-safe/ks-tx-builder.png) -**Step 2:** Open the Transaction Builder Safe app +\*\*ステップ 2: \*\* Transaction Builder Safe アプリを開きます。 ![](/img/build/tools/kaia-safe/ks-use-tx-builder.png) -**Step 3:** Enter your **token contract address** and **ABI**. +**ステップ3：**あなたの**トークン契約アドレス**と**ABI**を入力します。 -In this example, CCT contract address and ABI will be used. You can copy and paste your ABI into the **Enter ABI** field. +この例では、CCTの契約アドレスとABIが使われる。 あなたのABIをコピーして**Enter ABI**フィールドに貼り付けることができます。 ![](/img/build/tools/kaia-safe/kaia-safe-tx-builder-init.gif) -**Step 4:** Select a method and fill the transaction information +\*\*ステップ 4: \*\* 取引方法を選択し、取引情報を入力する。 -From the drop-down you can select a method. In this case, we select the **transfer** method. For this step to be completed, you have to fill out the transaction information, such as **to(address)** and **amount(uint256)**. +ドロップダウンからメソッドを選択できます。 この場合、**転送**方式を選択する。 このステップを完了するためには、\*\*to(address)**や**amount(uint256)\*\*といった取引情報を記入しなければならない。 -Note: The value is an unsigned integer without any decimals. In this example, the CCT token has 18 decimals. So if you want to send 10 CCT, you have to enter 10000000000000000000. +注：値は小数のない符号なし整数である。 この例では、CCTトークンの小数点以下は18桁である。 つまり、10CCTを送りたいなら、100000000000000000と入力しなければならない。 ![](/img/build/tools/kaia-safe/kaia-safe-tx-builder-details.gif) -**Step 5:** Click **Add transaction** +**ステップ5：** 取引の追加\*\*をクリックします。 -**Step 6:** Repeat steps **4**, **5**, and **6** for every recipient address. +**ステップ6:**受信者アドレスごとにステップ**4**、**5**、**6**を繰り返します。 -**Step 7:** Once you added all operations to the batch click **Create Batch** +**ステップ7：** すべての操作をバッチに追加したら、**Create Batch** をクリックします。 ![](/img/build/tools/kaia-safe/kaia-safe-tx-builder-batch.gif) -**Step 8:** Review and submit transaction +**ステップ 8：** 取引の確認と提出 -You'll be able to review the whole batch. Once ready, click **Send Batch** to submit and execute the transaction just like any other Safe transaction. +全バッチを見直すことができるようになる。 準備ができたら、**Send Batch** をクリックして、他の Safe 取引と同様に取引を送信し、実行します。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md index 213b89008b25..58870b70ed8a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md @@ -1,169 +1,169 @@ -# Use Kaia Safe +# カイアセーフを利用する -## Create a Safe +## 金庫を作る -Here you will see how to create a Safe and evaluate its benefits on the Kaia Network. +ここでは、カイア・ネットワークにおけるセーフの作成方法とその利点について説明します。 -**Step 1:** Navigate to [Kaia Safe App](https://safe.kaia.io/). By navigating to the application on your web browser, you can explore the functionality of Kaia Safe. +\*\*ステップ 1: \*\* [Kaia Safe App](https://safe.kaia.io/) に移動します。 ウェブブラウザでアプリケーションに移動すると、Kaia Safeの機能を調べることができます。 -**Step 2:** Connect your [wallet](https://docs.ethhub.io/using-ethereum/wallets/intro-to-ethereum-wallets/). At the moment, Kaia Safe support various wallets like [Kaia Wallet](https://docs.kaiawallet.io/), [MetaMask](../../../tutorials/connecting-metamask.mdx) wallet, etc. +**ステップ2:** [ウォレット](https://docs.ethhub.io/using-ethereum/wallets/intro-to-ethereum-wallets/)を接続します。 現在、Kaia Safeは、[Kaia Wallet](https://docs.kaiawallet.io/)、[MetaMask](../../../tutorials/connecting-metamask.mdx)ウォレットなど、様々なウォレットに対応しています。 -For the sake of this guide, we will be using MetaMask. Make sure you have Kaia networks([Mainnet](../../../tutorials/connecting-metamask.mdx#connect-to-kaia-network) or [Kairos Testnet](../../../tutorials/connecting-metamask.mdx#connect-to-kaia-network)) added to your MetaMask wallet to connect successfully. +このガイドでは、MetaMaskを使用する。 MetaMaskウォレットにKaiaネットワーク([Mainnet](../../../tutorials/connecting-metamask.mdx#connect-to-kaia-network)または[Kairos Testnet](../../../tutorials/connecting-metamask.mdx#connect-to-kaia-network)が追加されていることを確認してください。 ![](/img/build/tools/kaia-safe/kaia-safe-connect-wallet.png) -**Step 3:** Once your wallet is connected, click **Create Account** and give your new Safe a **name**. This name is linked to your safe account, which is a multi-signature wallet that holds and stores all of your funds. +**ステップ 3:** ウォレットが接続されたら、**Create Account**をクリックし、新しいセーフに\*\*「名前」\*\*を付けます。 この名前はあなたのセーフ・アカウントにリンクされています。セーフ・アカウントはマルチシグネチャーのウォレットで、あなたのすべての資金を保管・保存します。 -**Step 4:** Add owners/signers by inputting the addresses that have permission to submit and approve transactions. You can add as many signers as you want and remove or replace any of them at any time. +**ステップ4:** 取引を提出し承認する権限を持つアドレスを入力し、所有者/署名者を追加します。 署名者は何人でも追加でき、いつでも削除や入れ替えが可能です。 -**Step 5:** Choose how many signer confirmations a transaction in your Safe account needs to be approved. It is important to note that by default our app allows one signer confirmation. But it is advisable to use a threshold higher than 1 to ensure a secured safe account. Good practice is to use a threshold of 51% of the total owners e.g, 2 out of 3, 3 out of 5 etc as shown below: +**ステップ 5：** Safe 口座の取引が承認されるために必要な署名者の確認回数を選択します。 このアプリのデフォルトでは、署名者の確認は1人であることに注意してください。 しかし、安全な口座を確保するためには、1より高いしきい値を使用することをお勧めします。 例えば、3人中2人、5人中3人などである： ![](/img/build/tools/kaia-safe/kaia-safe-create-acct.gif) -**Step 6:** Review and deploy Safe +**ステップ6:** レビューとセーフの展開 -Once you are completely satisfied with all of your Safe parameters, you can submit the creation of your Safe account and proceed with the on-screen instructions to complete the account creation. +Safe のすべてのパラメータに完全に満足したら、Safe アカウントの作成を送信し、画面上の指示に従ってアカウント作成を完了します。 ![](/img/build/tools/kaia-safe/kaia-safe-create-review.gif) -Congratulations on successfully creating your Kaia Safe account! +カイアセーフのアカウント作成完了おめでとうございます！ -## Add assets +## 資産の追加 -In this section, you will see how to add assets (KAIA, FT, NFT) to your safe account and keep your funds safe. +このセクションでは、セーフアカウントに資産（KAIA、FT、NFT）を追加し、資金を安全に保管する方法をご紹介します。 -### KAIA Deposits +### KAIA預金 -Below are the steps to add **KAIA** to your safe account +以下は、**KAIA**をあなたのセーフアカウントに追加する手順です。 -**Step 1:** Copy your Safe address from your account dashboard. +**ステップ 1：** アカウントのダッシュボードからセーフアドレスをコピーします。 ![](/img/build/tools/kaia-safe/ks-deposit-copy-addr.png) -**Step 2:** Open your Metamask wallet and click **send** to send asset to your safe account. +\*\*ステップ 2: \*\* Metamask ウォレットを開き、**send** をクリックして資産を安全なアカウントに送信します。 -Note that there are different ways to send assets to your Safe account. You can send from your [hardware wallet](https://www.ledger.com/academy/crypto-hardware-wallet), [web wallet](https://medium.com/arcana-network-blog/why-web-wallets-e77c776e4d5e), or even a smart contract. In this case, we're making use of a web wallet called MetaMask. +Safe 口座に資産を送金するには、さまざまな方法があります。 あなたの[ハードウェアウォレット](https://www.ledger.com/academy/crypto-hardware-wallet)、[ウェブウォレット](https://medium.com/arcana-network-blog/why-web-wallets-e77c776e4d5e)、またはスマートコントラクトからも送信できます。 今回は、MetaMaskと呼ばれるウェブウォレットを利用する。 ![](/img/build/tools/kaia-safe/ks-token-send-btn.png) -**Step 3:** Paste your safe address in the search field as seen below. +\*\*ステップ3：\*\*以下のように、検索フィールドに安全なアドレスを貼り付けます。 -**Step 4:** Input **amount** and click **next**. +\*\*ステップ4：\*\*金額を入力し、**次へ**をクリックします。 ![](/img/build/tools/kaia-safe/ks-token-send-details.png) -**Step 5:** Confirm the transaction and check your asset dashboard. You can see the amount being transferred from your metamask account to your Kaia Safe account. +\*\*ステップ5： \*\*取引を確認し、資産ダッシュボードを確認します。 メタマスク口座からカイアセーフ口座への送金額が確認できます。 ![](/img/build/tools/kaia-safe/kaia-safe-klay-bal.png) -### KIP-7 Deposits +### KIP-7 預託金 -Now we will see how to deposit KIP7 (fungible tokens) to our safe by following the below steps. +それでは、以下の手順でKIP7（カンジブルトークン）を金庫に入金する方法を見ていきましょう。 -**Step 1:** Copy your Safe address from your account dashboard. +**ステップ 1：** アカウントのダッシュボードからセーフアドレスをコピーします。 ![](/img/build/tools/kaia-safe/ks-deposit-ft-copy.png) -**Step 2:** Open your Metamask Wallet and navigate to **assets** tab. +\*\*ステップ 2: \*\* Metamask Wallet を開き、**assets** タブに移動します。 -**Step 3:** Select the token you will love to send and click **send**. +\*\*ステップ3:\*\*送信したいトークンを選択し、**送信**をクリックします。 ![](/img/build/tools/kaia-safe/ks-ft-send-btn.png) -**Step 4:** Repeat step **3**, **4**, **5** of **KAIA** Deposits above. +**ステップ4： **上記の**KAIA**デポジットのステップ**3**, **4**, **5**を繰り返します。 ![](/img/build/tools/kaia-safe/ks-ft-send-details.png) -**Step 5:** View your assets dashboard, you can see the KIP7 tokens being transferred to your safe account. Similarly you can transfer any Fungible token to your safe account. +\*\*ステップ5：\*\*資産ダッシュボードを見ると、KIP7トークンが安全な口座に送金されているのがわかります。 同様に、Fungibleトークンを安全な口座に送金することもできます。 ![](/img/build/tools/kaia-safe/ks-ft-balance.png) -### KIP-17 (NFTs) Deposits +### KIP-17 (NFTs) 預金 -Now we will see how to deposit KIP17 (Non Fungible tokens) to our safe by following the steps below. +それでは、KIP17 (Non Fungible tokens)を私たちの金庫に入金する方法を以下の手順で見ていきましょう。 -You can transfer your NFT’s to your safe account in many different ways. Here is an example on how to transfer NFT to the safe account using [OpenSea](https://opensea.io/about). +NFTはさまざまな方法で金庫口座に振り込むことができます。 以下は、[OpenSea](https://opensea.io/about) を使用して NFT を安全口座に送金する方法の例です。 -1. Navigate to your [OpenSea account](https://testnets.opensea.io/account) profile page -2. Navigate to an NFT you ll love to transfer. Make sure to select a NFT on the Kaia Network(Mainnet or Kairos) -3. On the next page, click on the transfer button. -4. Paste the safe address in the text box and transfer to safe -5. Under Assets section in Kaia Safe you can find NFT’s from OpenSea. +1. OpenSeaアカウント](https://testnets.opensea.io/account)のプロフィールページに移動します。 +2. 移籍したいNFTへナビゲート。 必ずカイアネットワーク（メインネットまたはカイロス）上のNFTを選択してください。 +3. 次のページで、転送ボタンをクリックする。 +4. テキストボックスに金庫の住所を貼り付け、金庫に転送する。 +5. Kaia SafeのAssetsセクションにOpenSeaのNFTがあります。 ![](/img/build/tools/kaia-safe/kaia-safe-trf-nft.gif) -Please refer to this [guide](https://support.opensea.io/en/articles/8866959-how-can-i-transfer-an-nft-using-opensea) from OpenSea for more details on transferring NFTs. +NFTの移管の詳細については、OpenSeaのこちらの[ガイド](https://support.opensea.io/en/articles/8866959-how-can-i-transfer-an-nft-using-opensea)をご参照ください。 -## Send assets +## 資産を送る -In this section, you'll learn how to send KAIA and KIP-7 tokens from your Kaia Safe account. +このセクションでは、Kaia SafeアカウントからKAIAおよびKIP-7トークンを送信する方法について説明します。 -### Send KAIA & KIP7 Tokens +### KAIAおよびKIP7トークンの送信 -**Step 1:** Click the **New Transaction** button in the side menu and select **Send tokens** to begin a new asset transfer. +**ステップ1： **サイドメニューの**New Transaction**ボタンをクリックし、**Send tokens**を選択して、新しいアセットトランスファーを開始します。 ![](/img/build/tools/kaia-safe/kaia-safe-init-send-token.gif) -**Step 2:** Choose assets to transfer. +\*\*ステップ 2: \*\* 譲渡する資産を選択します。 - **KAIA** -> Note: Add the **recipient address** and the **amount** of KAIA to send the transfer KAIA. +> 注：KAIAを送金するために、**受取人のアドレス**と**KAIAの金額**を追加してください。 ![](/img/build/tools/kaia-safe/kaia-safe-send-token-details.gif) -- **KIP-7 Tokens** +- **KIP-7トークン** -Select the tokens you want to send in the asset drop-down as seen in the image above. +上の画像のように、アセットのドロップダウンで送信したいトークンを選択します。 -> Note: Add the recipient address and the number of tokens to transfer KIP7 tokens. +> 注：KIP7トークンを転送するために、受信者のアドレスとトークン数を追加します。 -**Step 3:** Review and submit the transaction. You will need to sign the transaction with your signer wallet, and it will be executed once the confirmation threshold is reached. +**ステップ3：** 取引を確認し、提出する。 取引は署名者ウォレットで署名する必要があり、確認のしきい値に達すると実行されます。 ![](/img/build/tools/kaia-safe/kaia-safe-review-send-tokens.gif) -### Send NFTs +### NFTを送る -In this section, you'll learn how to send your non-fungible tokens from your Kaia Safe account. +このセクションでは、カイアセーフアカウントから非有金トークンを送信する方法について説明します。 -**Step 1:** Click the **New Transaction** button in the side menu and select **Send NFTs** to begin a new asset transfer. +**ステップ1： **サイドメニューの**New Transaction**ボタンをクリックし、**Send NFTs**を選択して新しい資産譲渡を開始します。 ![](/img/build/tools/kaia-safe/kaia-safe-init-send-nft.gif) -**Step 2:** Choose assets to transfer. +\*\*ステップ 2: \*\* 譲渡する資産を選択します。 ![](/img/build/tools/kaia-safe/kaia-safe-send-nft-details.gif) -**Step 3:** Review and submit the transaction. You will need to sign the transaction with your signer wallet, and it will be executed once the confirmation threshold is reached. +**ステップ3：** 取引を確認し、提出する。 取引は署名者ウォレットで署名する必要があり、確認のしきい値に達すると実行されます。 ![](/img/build/tools/kaia-safe/kaia-safe-review-send-nft.gif) -## Further Notes +## その他の注意事項 -The following are things you will want to keep in mind while using Kaia Safe: +カイアセーフをご利用になる際にご留意いただきたいことを以下にまとめました： -### Transaction Fees +### 取引手数料 -Kaia Safe transactions, whether asset transfers or contract interactions, incur a fee that will be paid by the signer that executes the transaction (usually the last signer to reach the required threshold of signatures). +カイアセーフの取引は、資産の移転であれ契約のやり取りであれ、手数料が発生し、その手数料は取引を実行した署名者（通常、必要な署名数のしきい値に達した最後の署名者）が支払う。 -### Safe Nonce +### セーフ・ノンス -For security reasons, transactions made with Safe need to be executed in order. To achieve this, a number called **nonce** is assigned to a transaction to ensure that each transaction can be executed once. +セキュリティ上の理由から、Safeでの取引は順番に実行される必要があります。 これを実現するために、トランザクションには**nonce**と呼ばれる番号が割り当てられ、各トランザクションが一度しか実行できないようになっている。 ![](/img/build/tools/kaia-safe/ks-nounce.png) -At any given time, only transactions with a nonce _last executed transaction +1_ can be executed. Transactions with a higher nonce are queued for execution. So, whenever a transaction is completed, the next transaction in the queue is made available for execution, provided it has accumulated enough signatures. +任意の時点において、最後に実行されたトランザクション+1_ を持つトランザクションのみが実行可能である。 より高いnonceを持つトランザクションは実行のためにキューに入れられる。 そのため、トランザクションが完了するたびに、キュー内の次のトランザクションは、それが十分な署名を蓄積していれば、実行可能な状態になる。 ![](/img/build/tools/kaia-safe/ks-pending-tx.png) -### Chain-specific addresses +### チェーン別アドレス -You can choose to copy address with chain prefix +チェーン接頭辞付きのアドレスをコピーすることもできます。 -- Copy addresses with chain prefix: +- チェーン接頭辞付きのアドレスをコピーする： ![](/img/build/tools/kaia-safe/ks-chain-spec-addr.png) -When copying your safe address from your dashboard to paste in your wallet as seen above, you can either choose to add the chain name or not by clicking the checkbox. It is suggested that you leave it unchecked to avoid the error below. +ダッシュボードからセーフアドレスをコピーしてウォレットに貼り付ける場合、チェックボックスをクリックしてチェーン名を追加するかどうかを選択できます。 以下のエラーを避けるため、チェックを外しておくことをお勧めします。 ![](/img/build/tools/kaia-safe/ks-chain-addr-err.png) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md index ba97d9c1b88d..4b944f8e8874 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md @@ -1,33 +1,33 @@ -# Kaia Wallet +# カイア・ウォレット ![](/img/banners/kaia-kaiawallet.png) -Kaia Wallet is a browser extension wallet for the Kaia Network. Available in Google Chrome, Kaia Wallet provides a secure and usable means to interact with the Kaia network via web browser. With Kaia Wallet, you are able to store and transact with your KAIA and Kaia-based tokens. You are also able to sign requests from web-based dApps (Decentralized Applications) in -realtime. +カイアウォレットは、カイアネットワークのためのブラウザ拡張ウォレットです。 グーグル・クロームで利用可能なカイア・ウォレットは、ウェブ・ブラウザを通じてカイア・ネットワークとやりとりするための安全で使い勝手の良い手段を提供します。 KAIAウォレットを使えば、KAIAとKAIAベースのトークンを保管し、取引することができます。 また、ウェブベースのdApp（分散型アプリケーション）からのリクエストに +リアルタイムで署名することもできる。 -- Download from Chrome Web Store: [link](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) +- Chrome ウェブストアからダウンロードしてください：[リンク](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) -For developers, please visit [https://docs.kaiawallet.io](https://docs.kaiawallet.io) to learn how you can develop dApps using Kaia Wallet. +開発者の方は、[https://docs.kaiawallet.io](https://docs.kaiawallet.io)でカイアウォレットを使ったdAppsの開発方法をご覧ください。 -## PC web browser based decentralized HD wallet +## PCウェブブラウザベースの分散型HDウォレット -Kaia Wallet is a web browser extension available in Chrome. Kaia Wallet is optimized for the desktop environment. +カイア・ウォレットはクロームで利用可能なウェブ・ブラウザの拡張機能です。 カイアウォレットはデスクトップ環境に最適化されています。 -Kaia Wallet offers manageability of user accounts and keys. All transactions are transparently recorded on the Kaia blockchain, so anybody can access the transaction history by using [Kaiascope]. +カイアウォレットは、ユーザーアカウントとキーの管理性を提供します。 すべての取引はカイア・ブロックチェーン上に透過的に記録されるため、[Kaiascope]を使えば誰でも取引履歴にアクセスできる。 -Kaia Wallet is a Hierarchical Deterministic (HD) wallet, meaning that it generates a hierarchical tree-like structure of private/public keys indefinitely from a single seed phrase. The seed phrase consists of mnemonic code words, which makes it easier to remember than phrases made of random alphanumerics. Users' private keys are encrypted and stored in their browsers. +カイアウォレットは階層的決定論的（HD）ウォレットで、1つのシードフレーズから秘密鍵/公開鍵の階層ツリー構造を無限に生成します。 シードフレーズはニーモニックコードワードで構成されているため、ランダムな英数字で構成されたフレーズよりも覚えやすい。 ユーザーの秘密鍵は暗号化され、ブラウザに保存される。 -With the features described above, Kaia Wallet has improved the security, transparency, and user-friendliness of the current blockchain experience. However, it is vital for users to be responsible for managing their personal accounts. For example, if a user couldn't remember his/her seed phrase, there would be no other way to restore his/her accounts. +上記の機能により、カイア・ウォレットは現在のブロックチェーン体験の安全性、透明性、使いやすさを改善した。 しかし、利用者は個人アカウントの管理に責任を持つことが不可欠である。 例えば、ユーザーが自分のシードフレーズを思い出せなかった場合、アカウントを復元する他の方法はない。 -## Supporting various Kaia networks and tokens +## 様々なカイアネットワークとトークンに対応 -Kaia Wallet allows you to store and transact with all Kaia-based tokens including KAIA. Tokens that are not loaded by default can be inserted by pasting in their contract address. You can even store and transact your own Kaia-based custom tokens on Kaia Wallet! +カイア・ウォレットは、KAIAを含むすべてのカイアベーストークンの保管と取引を可能にします。 デフォルトでロードされていないトークンは、そのコントラクトアドレスを貼り付けることで挿入できる。 Kaiaウォレットには、独自のKaiaベースのカスタムトークンを保存して取引することもできる！ -Kaia Wallet supports Kaia's Kairos testnet as well as the Mainnet. Moreover, Kaia Wallet supports the private chains for Kaia-based dApp developers who may wish to circulate custom tokens in their private network. +Kaiaウォレットはメインネットと同様にKaiaのKairosテストネットをサポートしています。 さらに、カイアウォレットは、プライベートネットワークでカスタムトークンを流通させたいカイアベースのdApp開発者のためのプライベートチェーンをサポートしています。 -## Signing web-based dApp transactions +## ウェブベースのdAppトランザクションへの署名 -Kaia Wallet simply bridges the gap between you and dApps, empowering you to sign transactions/data flowing to you from dApps with Kaia Wallet account. -Kaia Wallet is also an aidful utility for developers to handle [fee-delegated transactions](../../../learn/transactions/transactions.md#fee-delegation). Using Kaia Wallet, both transaction senders and fee payers can swiftly sign the fee-delegated transactions. +カイアウォレットは、あなたとdAppsの間のギャップを埋めるだけで、カイアウォレットのアカウントでdAppsからあなたに流れる取引/データに署名する権限を与えます。 +カイア・ウォレットはまた、開発者が[手数料委任取引](../../../learn/transactions/transactions.md#fee-delegation)を処理するのに役立つユーティリティでもある。 カイア・ウォレットを使えば、取引の送り手と手数料の支払い手の双方が、手数料を委任された取引に迅速に署名することができる。 [Kaiascope]: ../block-explorers/kaiascope.md diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md index 574ba0f96a96..c5650e5c4630 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md @@ -2,266 +2,330 @@ sidebar_label: Particle Network --- -# Integrate Particle Network into a dApp +# パーティクルネットワークをdAppに統合する ![](/img/banners/kaia-particle.png) -## Introduction +## はじめに [Particle Network](https://particle.network)'s Wallet Abstraction services enable universal, Web2-adjacent onboarding and interactions. -The [Particle Connect SDK](https://developers.particle.network/api-reference/connect/desktop/web) supports EVM-compatible chains, including Kaia and its testnet. While traditional Web3 wallets are offered as connection mechanisms through Particle Connect, social logins through social accounts such as your email address, Google account, phone number, etc. are also available. If a user decides to log in with a Web2 account, you'll have the ability to call `getUserInfo` from `@particle-network/auth-core`, which will return an object containing key details such as their name, email, wallet addresses, etc. +Particle Connect SDK](https://developers.particle.network/api-reference/connect/desktop/web)は、Kaiaとそのテストネットを含むEVM互換チェーンをサポートしています。 [social and Web3 login options](https://developers.particle.network/api-reference/connect/desktop/web#wallet-connectors)を使って、2クリックオンボーディングを可能にします。 -With Particle Network, developers on Kaia can embed social logins for the Kaia Mainnet and testnet, allowing users to generate and use a wallet within your application using only their Google, email, X, etc. +Particle Networkを使えば、Kaiaの開発者はKaiaメインネットとテストネット用のソーシャルログインを埋め込むことができ、ユーザーはGoogle、Eメール、Xなどを使ってアプリケーション内でウォレットを生成し、使用することができます。 -This page offers an overview and tutorial for implementing Particle Connect within a Kaia-based application, to help you start the integration process. +このページでは、KaiaベースのアプリケーションにParticle Connectを実装するための概要とチュートリアルをご紹介します。 -## Prerequisites +## 前提条件 -- A [Next.js project](https://nextjs.org/docs/getting-started/installation) set up with TypeScript and Tailwind CSS - - You can create this by running: `npx create-next-app@latest` -- A project ID, client key, and app ID from the [Particle dashboard](https://dashboard.particle.network). +- TypeScriptとTailwind CSSを使った[Next.jsプロジェクト](https://nextjs.org/docs/getting-started/installation) + - これを作成するには、`npx create-next-app@latest` を実行します。 +- [Particle Dashboard] (https://dashboard.particle.network) から取得した **Project ID**、**Client Key**、および **App ID**。 -## Installation +## インストール -To leverage Particle Network, specifically Particle Connect, within your dApp, you'll need to first install the required libraries. The Particle Connect SDK streamlines wallet creation, user login, and blockchain interactions with one interface. It supports both social and Web3 logins for easy access. +Particle Network、特にParticle ConnectをdApp内で活用するには、まず必要なライブラリをインストールする必要があります。 Particle Connect SDKは、ウォレットの作成、ユーザーログイン、ブロックチェーンとのやり取りを1つのインターフェースで効率化します。 ソーシャルログインとWeb3ログインの両方をサポートし、簡単にアクセスできる。 -To install the SDK, along with Viem (backend for Connect) and ethers (demonstrating EIP-1193 providers), run: +SDKとViem（コネクトのバックエンド）、ethers（EIP-1193プロバイダーのデモ）をインストールするには、以下を実行する： ```shell -yarn add @particle-network/connectkit viem@^2 ethers +yarn add @particle-network/connectkit viem@^2エーテル ``` -## Initializing Particle Connect +## パーティクルコネクトの初期化 -To begin with, we’ll set up Particle Connect, Particle's flagship authentication SDK. Create a new file called `ConnectKit.tsx` in the root directory of your project. This file will house the `ParticleConnectKit` component, a wrapper for the configured `ConnectKitProvider` instance that serves as the primary interface for the configuration of Particle Connect (we'll go over what this looks like programmatically in a moment). +まずはじめに、Particleの代表的な認証SDKであるParticle Connectを設定します。 プロジェクトのルート・ディレクトリに `ConnectKit.tsx` という新しいファイルを作成します。 このファイルには `ParticleConnectKit` コンポーネントが格納されます。このコンポーネントは、設定された `ConnectKitProvider` インスタンスのラッパーであり、Particle Connect を設定するための主要なインターフェイスとして機能します（これがプログラムでどのように見えるかについては、後で説明します）。 To leverage Particle Network on alternative platforms, such as Android, iOS, React Native, Flutter, & Unity, kindly refer to Particle’s [documentation](https://developers.particle.network/reference/introduction-to-api-sdk-reference). -- **`projectId`** – a unique identifier for your project. -- **`clientKey`** – a key specific to your client. -- **`appId`** – the ID for your application. +- **`projectId`** - プロジェクトの一意な識別子。 +- **`clientKey`** - クライアント固有のキー。 +- **`appId`** - アプリケーションのID。 -Store these API keys in a `.env` file as follows: +これらのAPIキーを`.env`ファイルに以下のように格納する： ```plaintext -NEXT_PUBLIC_PROJECT_ID='PROJECT_ID' -NEXT_PUBLIC_CLIENT_KEY='CLIENT_KEY' -NEXT_PUBLIC_APP_ID='APP_ID' +next_public_project_id='project_id' +next_public_client_key='client_key' +next_public_app_id='app_id' ``` -Now, add the following code to your `ConnectKit.tsx` file: +次のコードを `ConnectKit.tsx` ファイルに追加してください： ```js -import { ModalProvider } from '@particle-network/connectkit'; -import { Klaytn, KlaytnTestnet } from '@particle-network/chains'; -import { evmWallets } from '@particle-network/connectors'; - -const root = ReactDOM.createRoot(document.getElementById('root') as HTMLElement); -root.render( - - - - - -); +"use client"; + +import React from "react"; +import { ConnectKitProvider, createConfig } from "@particle-network/connectkit"; +import { authWalletConnectors } from "@particle-network/connectkit/auth"; +import { defineChain } from "@particle-network/connectkit/chains"; +import { wallet, EntryPosition } from "@particle-network/connectkit/wallet"; + +const kaiaMainnet = defineChain({ + id: 8217, + name: "Kaia", + nativeCurrency: { + decimals: 18, + name: "KAIA", + symbol: "KAIA", + }, + rpcUrls: { + default: { + http: ["https://public-en.node.kaia.io"], + }, + }, + blockExplorers: { + default: { name: "Explorer", url: "https://kaiascope.com/" }, + }, + testnet: false, +}); + +const kaiaTestnet = defineChain({ + id: 1001, + name: "Kaia Testnet", + nativeCurrency: { + decimals: 18, + name: "KAIA", + symbol: "KAIA", + }, + rpcUrls: { + default: { + http: ["https://public-en-kairos.node.kaia.io"], + }, + }, + blockExplorers: { + default: { name: "Explorer", url: "https://kairos.kaiascope.com/" }, + }, + testnet: true, +}); + +const config = createConfig({ + projectId: process.env.NEXT_PUBLIC_PROJECT_ID!, + clientKey: process.env.NEXT_PUBLIC_CLIENT_KEY!, + appId: process.env.NEXT_PUBLIC_APP_ID!, + + walletConnectors: [authWalletConnectors({})], + + plugins: [ + wallet({ + entryPosition: EntryPosition.BR, // Positions the modal button at the bottom right on login + visible: true, // Determines if the wallet modal is displayed + }), + ], + chains: [kaiaMainnet, kaiaTestnet], +}); + +export const ParticleConnectkit = ({ children }: React.PropsWithChildren) => { + return {children}; +}; ``` -Virtually every property of this component can be configured, from the different login types you support to the visual appearance of the modal; to explore these various options, head over to [Particle's documentation](https://developers.particle.network/api-reference/connect/desktop/web#configuration). +このコンポーネントは、サポートするさまざまなログインタイプからモーダルの視覚的な外観まで、ほぼすべてのプロパティを設定できます。これらのさまざまなオプションを調べるには、[Particleのドキュメント](https://developers.particle.network/api-reference/connect/desktop/web#configuration)にアクセスしてください。 -## Integrate Particle Connect into Your App +## Particle Connectをアプリに統合 -Now that the configuration is complete, wrap your application with the `ParticleConnectKit` component to enable global access to the Particle Connect SDK. To achieve this, modify your `layout.tsx` file in the `src` directory as follows: +設定が完了したら、アプリケーションを `ParticleConnectKit` コンポーネントでラップし、Particle Connect SDK へのグローバルアクセスを有効にします。 そのためには、`src`ディレクトリにある`layout.tsx`ファイルを以下のように修正します： ```typescript -npm install --save @particle-network/connectkit -npm install --save @particle-network/chains -npm install --save @particle-network/connectors -npm install --save ethers +import { ParticleConnectkit } from '@/connectkit'; +import type { Metadata } from 'next'; +import { Inter } from 'next/font/google'; +import './globals.css'; + +const inter = Inter({ subsets: ['latin'] }); + +export const metadata: Metadata = { + title: 'Particle Connectkit App', + description: 'Generated by create next app', +}; + +export default function RootLayout({ + children, +}: { + children: React.ReactNode; +}) { + return ( + + + {children} + + + ); +} ``` -### Connecting Wallet +### コネクティング・ウォレット -With your `index.js` file setup, you can move onto connecting your users through a central "Connect Wallet" button. To do this, you can import `ConnectButton` from `@particle-network/connectkit` alongside its corresponding css. Upon using `ConnectButton` within your `App` component, a standard "Connect Wallet" button will appear to facilitate connection. +`layout.tsx`ファイルのセットアップが完了したら、中央の**Connect Wallet**ボタンを使ってユーザーを接続します。 これを行うには `@particle-network/connectkit` から `ConnectButton` をインポートします。 ユーザーがログインすると、`ConnectButton`は埋め込みウィジェットに変わります。 ```js -import '@particle-network/connectkit/dist/index.css'; -import { ConnectButton } from '@particle-network/connectkit'; +import { ConnectButton, useAccount } from '@particle-network/connectkit'; export const App = () => { - return ; + const { address, isConnected, chainId } = useAccount(); + + // Standard ConnectButton utilization + return ( +
+ + {isConnected && ( + <> +

Address: {address}

+

Chain ID: {chainId}

+ + )} +
+ ); }; ``` -### Getting Account and Balance +### アカウントと残高の取得 -With a wallet now successfully connected through `ConnectButton`, you can retrieve the users associated Klaytn address. Additionally, you can retrieve its current balance (in KLAY) through ethers.js, passing in the corresponding EIP-1193 provider object retrieved from `useParticleProvider` within `@particle-network/connectkit`. +`ConnectButton`コンポーネントを通してウォレット（またはソーシャルログイン）が接続されると、ユーザーの関連するKaiaアドレスを取得することができます。 さらに、（KAIAの）現在の残高を`publicClient`を通して取得することができます。これは、Particle Connectによってすでに設定されているViemプロバイダを利用します。 ```js - // add to the existing useState hook. - const [txHash, setTxHash] = useState(); - - const sendKaia = async () => { - - if (!provider) { - console.log("provider not initialized yet"); - return; +"use client"; + +import { useState, useEffect } from "react"; +import { + ConnectButton, + useAccount, + usePublicClient, +} from "@particle-network/connectkit"; +import { formatEther } from "viem"; + +export default function Home() { + // Account-related states + const { isConnected, address, chain } = useAccount(); + const publicClient = usePublicClient(); + + // State variable for balance + const [balance, setBalance] = useState(""); + + // Fetch and display user balance when connected + useEffect(() => { + const fetchBalance = async () => { + if (address) { + try { + const balanceResponse = await publicClient.getBalance({ address }); + const balanceInEther = formatEther(balanceResponse); + setBalance(balanceInEther); + } catch (error) { + console.error("Error fetching balance:", error); + } } - const destination = "paste recipient address"; - - // this guide uses ethers version 6.3.0. - const ethersProvider = new ethers.BrowserProvider(provider); - // for ethers version below 6.3.0. - // const provider = new ethers.providers.Web3Provider(provider); - - const signer = await ethersProvider.getSigner(); - - // Submit transaction to the blockchain and wait for it to be mined - const tx = await signer.sendTransaction({ - to: destination, - value: ethers.parseEther("0.1"), - maxPriorityFeePerGas: "5000000000", // Max priority fee per gas - maxFeePerGas: "6000000000000", // Max fee per gas - }) - - - const receipt = await tx.wait(); - setTxHash(receipt.hash) -} - -return ( -
- -
Send-Kaia Tx Hash : {txHash ? Kaiascope : ' ' }
+ }; + + if (isConnected) { + fetchBalance(); + } + }, [isConnected, address, publicClient]); + + return ( +
+ + {isConnected && ( +
+

Account Details

+

+ Address: {address || "Loading..."} +

+

+ Balance: {balance || "Loading..."} {chain?.nativeCurrency.symbol} +

+
+ )}
-); - + ); +} ``` -### Disconnecting Wallet +### ウォレットの切断 -Once a user has logged in, you can programmatically force a logout through `disconnect` derived from `useParticleConnect`. This will disconnect the current active session from your dApp, returning the user to their initial state. +一度ログインしたユーザは、プログラムによって `useDisconnect` から派生した `disconnect` によって強制的にログアウトさせることができる。 これは現在アクティブなセッションをdAppから切断し、ユーザーを初期状態に戻します。 ```js -import { useParticleConnect } from '@particle-network/connectkit'; +import { useDisconnect } from "@particle-network/connectkit"; -const { disconnect } = useParticleConnect(); +const { disconnect } = useDisconnect(); -function App() { - -const disconnectUser = async () => { - await disconnect(); - refreshState(); -} +// Inside your component's JSX + -// refresh state -const refreshState = () => { - setAddress(); - setBalance(); -// make sure to add every other useState modifier function declared here. -} - -return ( -
- -
- ); -} ``` -### Getting User Info +### ユーザー情報の取得 -When a user connects via social accounts, you can use the `useParticleAuth()` hook to access `userinfo`, which includes details about their connection method, account creation date, name, emails, and other [relevant information from Particle Auth](https://developers.particle.network/api-reference/connect/desktop/web#fetch-user-information-with-particle-auth). +ユーザーがソーシャルアカウント経由で接続すると、フック `useParticleAuth()` を使って `userinfo` にアクセスすることができます。この情報には、接続方法、アカウント作成日、名前、メールアドレス、その他の [Particle Auth の関連情報](https://developers.particle.network/api-reference/connect/desktop/web#fetch-user-information-with-particle-auth) に関する詳細が含まれます。 ```js -import { getUserInfo } from '@particle-network/auth-core'; +import { useAccount, useParticleAuth, useWallets } from '@particle-network/connectkit'; +import { useState, useEffect } from 'react'; -const [userData, setUserData] = useState({}); - -const getUserInfo = async () => { - const user = getUserInfo(); - setUserData(user); -}; +export const App = () => { + const { getUserInfo } = useParticleAuth(); + const { isConnected } = useAccount(); -return ( -
- -

User Email: { userData ? ` ${userData.google_email}` : "Nil"}

-
- ); + // Retrieve the primary wallet from the Particle Wallets + const [primaryWallet] = useWallets(); + + // Store userInfo in a useState to use it in your app + const [userInfo, setUserInfo] = useState(null); + + useEffect(() => { + const fetchUserInfo = async () => { + // Use walletConnectorType as a condition to avoid account not initialized errors + if (primaryWallet?.connector?.walletConnectorType === 'particleAuth') { + const userInfo = await getUserInfo(); + setUserInfo(userInfo); + } + }; + + fetchUserInfo(); + }, [isConnected, getUserInfo]); + + return

Name: {userInfo.name || 'N/A'}

; +}; ``` -### Sending Native Transaction +### ネイティブ・トランザクションの送信 -Particle Connect allows you to leverage an already existing EIP-1193 provider, in this example we create a provider instance with `ethers` to send a transfer transaction. +Particle Connectでは、すでに存在するEIP-1193プロバイダを活用できます。この例では、`ethers`でプロバイダインスタンスを作成し、転送トランザクションを送信します。 ```js -import { useParticleProvider } from '@particle-network/connectkit'; +import { useWallets } from "@particle-network/connectkit"; +import { ethers, type Eip1193Provider } from "ethers"; -const provider = useParticleProvider(); +const [primaryWallet] = useWallets(); -const [address, setAddress] = useState(""); -const [balance, setBalance] = useState(""); +const executeTransaction = async () => { + // Get the provider from the primary wallet's connector + const EOAprovider = await primaryWallet.connector.getProvider(); -const getWalletAndBalance = async() => { - // this guide uses ethers version 6.3.0. - const ethersProvider = new ethers.BrowserProvider(provider); - // for ethers version below 6.3.0. - // const provider = new ethers.providers.Web3Provider(web3authProvider); + // Initialize a custom provider using ethers.js with the obtained EIP-1193 provider + const customProvider = new ethers.BrowserProvider(EOAprovider as Eip1193Provider, "any"); - const signer = await ethersProvider.getSigner(); + // Get the signer (an abstraction of the account that can sign transactions) + const signer = await customProvider.getSigner(); - // Get user's Ethereum public address - const address = signer.address; - - // Get user's balance in ether - const balance = ethers.formatEther( - await ethersProvider.getBalance(address) // balance is in wei - ); + // Send a transaction with specified recipient address, amount (0.01 ETH), and empty data + await signer.sendTransaction({ + to: recipientAddress, + value: parseEther("0.01"), + data: "0x", + }); +}; - setAddress(address); - setBalance(balance); -return ( -
- -
Wallet Address: ${address} Balance: ${balance}
-
- ); -} ``` -## Next Steps +## 次のステップ -You can find a complete list of hooks available on the [Particle Connect docs](https://developers.particle.network/api-reference/connect/desktop/web#key-react-hooks-for-particle-connect). +利用可能なフックの完全なリストは、[Particle Connect docs](https://developers.particle.network/api-reference/connect/desktop/web#key-react-hooks-for-particle-connect)にあります。 -For additional guides regarding Particle Network (Particle Connect, Particle Auth, and other SDKs), please refer to the [Particle Network docs](https://developers.particle.network) and the [Particle Network GitHub account](https://github.com/Particle-Network). Additionally, you may want to visit the [Particle Network blog](https://blog.particle.network) for additional information on Particle Network's services, upcoming releases, and tech stack. +Particle Network（Particle Connect、Particle Auth、およびその他のSDK）に関するその他のガイドについては、[Particle Network docs](https://developers.particle.network)および[Particle Network GitHubアカウント](https://github.com/Particle-Network)を参照してください。 さらに、Particle Networkのサービス、今後のリリース、技術スタックに関する追加情報については、[Particle Networkブログ](https://blog.particle.network)をご覧ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md index 2d64a03cb63c..4e4843421dab 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md @@ -2,45 +2,45 @@ sidebar_label: Privy --- -# Integrate Privy into a dApp +# PrivyをdAppに統合する ![](/img/banners/kaia-privy.png) -## Introduction +## はじめに -[Privy](https://docs.privy.io/) is a simple wallet toolkit for progressive authentication in web3. With Privy, developers can onboard users using traditional and web3 authentication methods, enabling progressive onboarding to boost user conversion. +[Privy](https://docs.privy.io/) は、Web3におけるプログレッシブ認証のためのシンプルなウォレットツールキットです。 Privyを使用すると、開発者は従来の認証方法とWeb3認証方法を使用してユーザーをオンボーディングすることができ、ユーザーのコンバージョンを高めるプログレッシブオンボーディングが可能になります。 -In this guide, you will use Privy wallet toolkit to integrate external wallets such as Metamask, Coinbase Wallet, and social logins such as Google, Twitter, Email into your dApp built on the Klaytn Network. +このガイドでは、Privy wallet toolkitを使用して、Metamask、Coinbase Wallet、Google、Twitter、Emailなどのソーシャルログインなどの外部ウォレットをKaia Network上に構築したdAppに統合します。 -## Prerequisite +## 前提条件 -- A working Next.js project. You can clone this [create-next-app](https://github.com/privy-io/create-next-app) template provided by Privy to follow along in this tutorial. -- An [appID](https://docs.privy.io/guide/console/api-keys#app-id) from the [Privy developer console](https://console.privy.io/) +- 動くNext.jsプロジェクト。 Privyが提供するこの[create-next-app](https://github.com/privy-io/create-next-app)テンプレートをクローンして、このチュートリアルに沿って進めることができる。 +- Privy開発者コンソール](https://console.privy.io/)からの[appID](https://docs.privy.io/guide/console/api-keys#app-id)。 -## Getting Started +## はじめに -The cloned template is a simple Next.js Privy Auth Starter template with three main core files: +クローンされたテンプレートは、シンプルなNext.js Privy Auth Starterテンプレートです： -- **index.tsx**: this file handles the login authentication of users. -- **app.tsx**: this file handles the initialization of Privy SDK and wraps our components with a PrivyProvider. -- **dashboard.tsx**: this is the page users are redirected to after logging in. It handles everything around testing each login method (Google, Twitter, Email, Wallets). More importantly for this guide, we will perform certain functionalities when connected using external wallets like MetaMask. These functionalities include: getting user balance, sending KLAY to another account, deploying a contract, interacting with a smart contract. +- **index.tsx**：このファイルは、ユーザーのログイン認証を処理する。 +- **app.tsx**：このファイルはPrivy SDKの初期化を処理し、PrivyProviderでコンポーネントをラップします。 +- **dashboard.tsx**：ログイン後にユーザーがリダイレクトされるページです。 各ログイン方法（Google、Twitter、Eメール、ウォレット）のテストにまつわるすべてを処理する。 このガイドでもっと重要なのは、MetaMaskのような外部ウォレットを使って接続したときに特定の機能を実行することだ。 These functionalities include: getting user balance, sending KLAY to another account, deploying a contract, interacting with a smart contract. -## Installation +## インストール -To make use of Privy in your dApp, you must install the required libraries and SDK first. Hence, you'll need to set up ethers.js, and the [Privy React Auth SDK](https://www.npmjs.com/package/@privy-io/react-auth). You can use Privy together with either [ethers.js](https://docs.ethers.org/v6/), [web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html), [viem](https://viem.sh/) libraries to communicate with the Klaytn blockchain. For the sake of this guide, we will use the ethers.js library. +あなたのdAppでPrivyを利用するには、まず必要なライブラリとSDKをインストールする必要があります。 したがって、ethers.jsと[Privy React Auth SDK](https://www.npmjs.com/package/@privy-io/react-auth)をセットアップする必要がある。 Privyは、[ethers.js](https://docs.ethers.org/v6/)、[web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html)、[viem](https://viem.sh/)のいずれかのライブラリと一緒に使って、カイア・ブロックチェーンと通信することができます。 このガイドでは、ethers.jsライブラリを使用する。 -Open up your project folder and run the command below to install the required libraries and SDK: +プロジェクトフォルダを開き、以下のコマンドを実行して必要なライブラリとSDKをインストールします： ```bash npm install —save @privy-io/react-auth npm install --save ethers ``` -## Initializing Privy and Privy Provider +## PrivyとPrivy Providerの初期化 -After successfully installing the needed libraries, next is to wrap your components with a [PrivyProvider](https://docs.privy.io/reference/react-auth/modules#privyprovider). +必要なライブラリのインストールに成功したら、次はコンポーネントを[PrivyProvider](https://docs.privy.io/reference/react-auth/modules#privyprovider)でラップする。 -The PrivyProvider should wrap any component that will use the Privy SDK. To do so, open up the _app.tsx file and paste the code below: +PrivyProviderは、Privy SDKを使用するすべてのコンポーネントをラップする必要があります。 そのためには、_app.tsxファイルを開き、以下のコードを貼り付ける： ```tsx import '../styles/globals.css'; @@ -68,16 +68,16 @@ function MyApp({Component, pageProps}: AppProps) { export default MyApp; ``` -It’s important to note that the Privy provider takes the following properties: +プリヴィー・プロバイダーが以下のプロパティを取ることに注意することが重要である： -- Your `appID`, which needs to be updated in your .env file. You can get started with the following `test App ID: clpispdty00ycl80fpueukbhl` as provided by Privy for test purposes. -- An optional `onSuccess` callback which will execute once a user successfully logs in. -- An optional `createPrivyWalletOnLogin` boolean to configure whether you'd like your users to create embedded wallets when logging in. -- An optional config property to customize your onboarding experience. +- .envファイルで更新する必要があります。 テスト用にPrivyから提供された`test App ID: clpispdty00ycl80fpueukbhl`で始めることができる。 +- オプションの `onSuccess` コールバックは、ユーザがログインに成功すると実行される。 +- オプションの `createPrivyWalletOnLogin` boolean で、ログイン時に埋め込みウォレットを作成させるかどうかを設定します。 +- オンボーディング体験をカスタマイズするためのオプションの設定プロパティです。 -## Connecting Wallet +## コネクティング・ウォレット -Inside your LoginPage function in your `index.tsx` file, call the [login](https://docs.privy.io/reference/react-auth/interfaces/PrivyInterface#login) method which opens the Privy login modal and prompts the user to login. +`index.tsx`ファイル内のLoginPage関数内で、[login](https://docs.privy.io/reference/react-auth/interfaces/PrivyInterface#login) メソッドを呼び出します。このメソッドは、Privyのログインモーダルを開き、ユーザーにログインを促します。 ```ts import {usePrivy} from '@privy-io/react-auth'; @@ -95,11 +95,11 @@ Inside your LoginPage function in your `index.tsx` file, call the [login](https: ![](/img/build/tools/privy-connect-banner.png) -## Getting Account and Balance +## アカウントと残高の取得 -From the previous step above, you'll realize we logged in by connecting our wallet. In this step, we will retrieve the user’s associated Klaytn address. Additionally, you can retrieve its current balance (in KLAY) using ethers.js. +先ほどのステップで、ウォレットを接続してログインしたことがわかるだろう。 このステップでは、ユーザーの関連するカイアのアドレスを取得する。 Additionally, you can retrieve its current balance (in KLAY) using ethers.js. -In your dashboard.tsx file, paste the code below: +dashboard.tsxファイルに以下のコードを貼り付けます： ```tsx import {useRouter} from 'next/router'; @@ -138,16 +138,16 @@ return ( {ready && authenticated ? (
-

{balance ? ` User with ${wallets[0].address} has ${balance} KLAY` : "None"}

+

{balance ? ` User with ${wallets[0].address} has ${balance} KAIA` : "None"}

) : null } ); ``` -## Disconnecting Wallet +## ウォレットの切断 -Disconnecting Wallet -Once a user has logged in, you can programmatically log the user out through the `logout` method derived from usePrivy. This will disconnect the current active session from your dApp, returning the user to their initial state. +ウォレットを切断する +ユーザーがログインしたら、usePrivy から派生した `logout` メソッドを使って、プログラムでユーザーをログアウトさせることができます。 これは現在アクティブなセッションをdAppから切断し、ユーザーを初期状態に戻します。 ```tsx const { logout } = usePrivy(); @@ -162,9 +162,9 @@ return ( ); ``` -## Getting User Info +## ユーザー情報の取得 -Privy offers users the comfort of connecting to a dApp using both web3 wallets and social logins. In the case where a user connects to a dApp using their social account such as twitter, discord, google account etc, you ll have the ability to call `user` from `usePrivy`, which will return an object containing key details such as their id, email, wallet addresses, etc. +Privyは、ユーザーにウェブ3ウォレットとソーシャルログインの両方を使用してdAppに接続する快適さを提供します。 ユーザーがtwitterやdiscord、googleアカウントなどのソーシャルアカウントを使ってdAppに接続する場合、`usePrivy`から`user`を呼び出すことができる。 ```tsx const { user } = usePrivy(); @@ -181,7 +181,7 @@ return ( ); ``` -## Sending Native Transaction +## ネイティブ・トランザクションの送信 You can perform native transactions, like sending KLAY from one user to another. @@ -212,17 +212,17 @@ return ( {ready && authenticated ? (
-

{klayTransferTx ? `KLAY Successfully Transferred with: ${klayTransferTx} hash` : "No Tx yet"}

+

{klayTransferTx ? `KAIA Successfully Transferred with: ${klayTransferTx} hash` : "No Tx yet"}

) : null } ); ``` -## Working with a Smart Contract +## スマートコントラクトとの連携 -### 1. Deploying a Contract +### 1. 契約の展開 -You can deploy a smart contract given its Application Binary Interface(ABI) and its contract byte code. +スマート・コントラクトは、アプリケーション・バイナリ・インターフェース（ABI）とコントラクトのバイトコードによってデプロイできる。 ```tsx // add to the existing useState hook. @@ -296,7 +296,7 @@ return ( ); ``` -### 2. Writing to a Contract +### 2. 契約書への書き込み ```tsx const [contractWriteTx, setContractTx] = useState(""); @@ -375,7 +375,7 @@ return ( ); ``` -### 3. Reading from a Contract +### 3. 契約書を読む ```tsx const [readContractMessage, setContractMessage] = useState(); @@ -447,6 +447,6 @@ return ( ); ``` -## Next Steps +## 次のステップ -For more in-depth guides on Privy, please refer to the [Privy Docs](https://docs.privy.io/) and [Privy Github repository](https://github.com/privy-io). Also, you can find the full implementation of the code for this guide on [GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/wallet-libraries/privy-auth-sample). +Privyに関するより詳細なガイドについては、[Privy Docs](https://docs.privy.io/)および[Privy Githubリポジトリ](https://github.com/privy-io)を参照してください。 また、このガイドのコードの完全な実装は[GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/wallet-libraries/privy-auth-sample)にあります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/wallet-libraries.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/wallet-libraries.md index 97a43d192ce3..c55ef263094b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/wallet-libraries.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/wallet-libraries.md @@ -1,6 +1,6 @@ -# Wallet Libraries +# 財布ライブラリ -Let's see how to integrate well-known wallet libraries into dApp. +有名なウォレットライブラリをdAppに統合する方法を見てみよう。 ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Auth.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Auth.mdx index dca6cfc2586e..1fa0379213df 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Auth.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Auth.mdx @@ -2,38 +2,38 @@ sidebar_label: Web3Auth --- -# Integrate Web3Auth into a dApp +# Web3AuthをdAppに統合する ![](/img/banners/kaia-web3Auth.png) -## Introduction +## はじめに -[Web3Auth](https://web3auth.io/docs/) is a wallet infrastructure that is plugged into dApps or wallets. It serves as a pluggable authentication infrastructure for web3 wallets and applications. With Web3Auth's excellent user experience, both mainstream and crypto natives may be onboarded in a matter of minutes. +[Web3Auth](https://web3auth.io/docs/)は、dAppsやウォレットにプラグインされるウォレットインフラストラクチャである。 Web3ウォレットとアプリケーションのためのプラグイン可能な認証インフラストラクチャとして機能します。 Web3Authの優れたユーザーエクスペリエンスにより、メインストリームと暗号化ネイティブの両方が、数分で参加できる可能性がある。 -As a wallet infrastructure, it provides out-of-the-box support for all social logins, web and mobile native platforms, wallets, and other key management methods. By the end of this guide, you will have integrated Web3Auth into your decentralized web application built on the Kaia Network. To integrate Web3Auth into other platforms (Android, iOS, React Native, Flutter, & Unity), kindly refer to this [guide](https://web3auth.io/docs/quick-start). +ウォレット・インフラストラクチャとして、あらゆるソーシャル・ログイン、ウェブおよびモバイルのネイティブ・プラットフォーム、ウォレット、その他の鍵管理方法をすぐにサポートする。 このガイドが終わる頃には、Web3AuthをKaia Network上に構築された分散型ウェブアプリケーションに統合していることでしょう。 Web3Authを他のプラットフォーム（Android、iOS、React Native、Flutter、Unity）に統合するには、こちらの[ガイド](https://web3auth.io/docs/quick-start)を参照してください。 -For a quick start, the complete code for this tutorial is available on [GitHub](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/web3Auth.md). You can clone or download the repository to follow along. +手っ取り早く始めるために、このチュートリアルの完全なコードは[GitHub](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/web3Auth.md)にあります。 レポジトリをクローンするか、ダウンロードすることでフォローすることができる。 -## Prerequisite +## 前提条件 -* A working react project (by executing `npm create vite@latest project-name -- --template react-ts`) -* Install the necessary wallets ([Coinbase Wallet](https://www.coinbase.com/wallet/downloads), [Metamask](https://metamask.io/download/)). -* RPC Endpoint: you can get this from one of the supported [endpoint providers](../../../../references/public-en.md). -* Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. -* Get your Client ID from [Web3Auth Dashboard](https://dashboard.web3auth.io/). +* 動作中のreactプロジェクト（`npm create vite@最新のプロジェクト名 -- --template react-ts` を実行する）。 +* 必要なウォレット（[Coinbase Wallet](https://www.coinbase.com/wallet/downloads)、[Metamask](https://metamask.io/download/)）をインストールします。 +* RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](../../../../references/public-en.md)の1つから取得できます。 +* [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 +* Web3Auth Dashboard](https://dashboard.web3auth.io/)からクライアントIDを取得します。 -## Installation +## インストール -To make use of Web3Auth in your dApp, you must install the required libraries and SDK first. Hence, you'll need to set up ethers.js, and the Web3Auth Web SDK. You can use Web3Auth together with either [ethers.js](https://docs.ethers.org/v6/), [web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html) or [kaia sdk](https://docs.kaia.io/references/sdk/ethers-ext/getting-started/) libraries to communicate with the Kaia blockchain. We'll be using ethers.js for this guide. +dAppでWeb3Authを利用するには、まず必要なライブラリとSDKをインストールする必要があります。 したがって、ethers.jsとWeb3Auth Web SDKをセットアップする必要がある。 Web3Authは、[ethers.js](https://docs.ethers.org/v6/)、[web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html)、または[kaia sdk](https://docs.kaia.io/references/sdk/ethers-ext/getting-started/)ライブラリのいずれかと一緒に使用して、カイアブロックチェーンと通信することができます。 このガイドではethers.jsを使用します。 ```bash npm install --save @web3auth/modal @web3auth/base @web3auth/ethereum-provider @web3auth/default-evm-adapter npm install --save ethers ``` -## Initializing Web3Auth and Provider Instance +## Web3Authとプロバイダーインスタンスを初期化する -After successfully installing the needed libraries, next is to initialize the Web3Auth instance, set the Web3Auth **provider** instance in a `useState()` hook and also the `init()` function in a `useEffect()` hook. +必要なライブラリのインストールに成功したら、次は Web3Auth インスタンスを初期化する。Web3Auth **provider** インスタンスを `useState()` フックに設定し、`init()` 関数を `useEffect()` フックに設定する。 @@ -300,7 +300,7 @@ After successfully installing the needed libraries, next is to initialize the We import { nodePolyfills } from 'vite-plugin-node-polyfills' export default defineConfig({ - plugins: [ + plugins：[ react(), nodePolyfills({ globals: { @@ -311,8 +311,8 @@ After successfully installing the needed libraries, next is to initialize the We protocolImports: true, }), ], - define: { - 'process.env': {}, + define：{ + 'process.env'：{}, global: 'globalThis', }, }) @@ -322,45 +322,45 @@ After successfully installing the needed libraries, next is to initialize the We --- - Import Web3Auth and other dependent packages. + Web3Authとその他の依存パッケージをインポートする。 ```js App.tsx focus=1:10 ``` --- - Import React hooks (useState and useEffect) and utility functions: + Reactフック（useStateとuseEffect）とユーティリティ関数をインポートする： - * `useState` and `useEffect`: React hooks for state management and side effects. - * `RPC`: Custom utility functions from `etherRPC.ts` for Ethereum-compatible blockchain interactions using ethers.js. + * `useState`と `useEffect`：状態管理と副作用のための React フック。 + * `RPC`：ethers.js を使用したイーサリアム互換ブロックチェーンとのインタラクションのための `etherRPC.ts` からのカスタムユーティリティ関数。 ```js App.tsx focus=13:15 ``` --- - Paste your **Client ID** from the Web3Auth Dashboard. + Web3Authダッシュボードから**クライアントID**を貼り付けます。 ```js App.tsx focus=16:17 ``` --- - Setup **Chain Config**: To use Web3Auth, you need to set up a chain config for the selected chain - Kaia. + チェーンコンフィグを設定するWeb3Authを使用するには、選択したチェーン（Kaia）のチェーン設定を行う必要があります。 ```js App.tsx focus=18:27 ``` --- - Initialize Web3Auth by using the constructor, where you can pass all the configurations of Web3Auth you want. + コンストラクタを使用して Web3Auth を初期化し、Web3Auth のすべての設定を渡します。 ```js App.tsx focus=27:44 ``` --- - Set the Web3Auth **provider** instance, **userInfo** in a `useState()` hook and the `init()` function in a `useEffect()` hook. + `UseState()` フックに Web3Auth の **provider** インスタンス、**userInfo** を設定し、`useEffect()` フックに `init()` 関数を設定する。 ```js App.tsx focus=53:95 ``` @@ -368,9 +368,9 @@ After successfully installing the needed libraries, next is to initialize the We --- -## Connecting Wallet +## コネクティング・ウォレット -Inside your App function in your `App.tsx` file, call the [connect()](https://web3auth.io/docs/sdk/pnp/web/modal/usage?product=PNP\&sdk=PNP_MODAL\&framework=REACT\&stepIndex=0\&stepIndex=6#logging-in-the-user) method on the web3Auth instance to initiate the connection of your wallet. +`App.tsx`ファイルのApp関数内で、web3Authインスタンスの[connect()](https://web3auth.io/docs/sdk/pnp/web/modal/usage?product=PNP\&sdk=PNP_MODAL\&framework=REACT\&stepIndex=0\&stepIndex=6#logging-in-the-user)メソッドを呼び出し、ウォレットの接続を開始します。 ```js function App() { @@ -400,13 +400,13 @@ function App() { ![](/img/build/tools/web3Auth-login.png) -## Setting up Utils function +## ユーティリティ機能の設定 -In this guide, we will be making use of utils function: `truncateAddress()`. The truncateAddress() function takes in a valid address and returns a more readable format of the address passed in. The following steps below show how to set up and use the utils function in your project. +このガイドでは、ユーティリティ関数 `truncateAddress()` を使用します。 truncateAddress()関数は、有効なアドレスを受け取り、渡されたアドレスをより読みやすい形式で返す。 以下のステップは、プロジェクトでutils関数をセットアップして使用する方法を示しています。 -**Step 1**: Create a `utils.ts` file in the `src` root folder. +**ステップ 1**：ルートフォルダ `src` に `utils.ts` ファイルを作成する。 -Paste the following code in the newly created utils.ts file: +新しく作成したutils.tsファイルに以下のコードを貼り付ける： ```js export const truncateAddress = (address) => { @@ -419,15 +419,15 @@ export const truncateAddress = (address) => { } ``` -**Step 2**: Import the function in your `App.tsx` file. +**ステップ 2**：App.tsx\`ファイルに関数をインポートします。 ```js import { truncateAddress } from './utils' ``` -## Getting Account and balance +## アカウントとバランスの取得 -Having connected your wallet successfully by calling the `connect()` method on the Web3Auth instance, you can get the user account and its balance by using the provider and signer object. +Web3Auth インスタンスで `connect()` メソッドを呼び出してウォレットとの接続に成功したら、プロバイダと署名者オブジェクトを使用してユーザーアカウントとその残高を取得できます。 ```js function App() { @@ -479,9 +479,9 @@ function App() { } ``` -## Disconnecting Wallet +## ウォレットの切断 -Disconnecting from the wallet is achieved by using the [logout()](https://web3auth.io/docs/sdk/web/no-modal/usage#logging-out-the-user) method on the Web3Auth instance. Also, one good practice is to refresh the state to clear any previously stored connection data. +ウォレットとの接続を解除するには、Web3Auth インスタンスの [logout()](https://web3auth.io/docs/sdk/web/no-modal/usage#logging-out-the-user) メソッドを使用します。 また、以前に保存された接続データをクリアするために、ステートをリフレッシュすることも良い習慣のひとつである。 ```js function App() { @@ -508,9 +508,9 @@ function App() { } ``` -## Getting User Info +## ユーザー情報の取得 -A unique feature of Web3Auth is social logins. Once a user login using their social platforms, Web3Auth instance returns some information about the logged in user. Getting the logged in user information is as simple as calling the `getUserInfo()` method on the Web3Auth instance. +Web3Authのユニークな機能は、ソーシャルログインである。 ユーザーがソーシャルプラットフォームを使ってログインすると、Web3Authインスタンスはログインしたユーザーに関する情報を返します。 ログインしているユーザー情報を取得するには、Web3Authインスタンスの `getUserInfo()` メソッドを呼び出すだけです。 ```js const [userInfo, setUserInfo] = useState(null); @@ -539,9 +539,9 @@ return ( ) ``` -## Signing Messages +## 署名メッセージ -Having initialised the provider and signer object, users can sign an arbitrary string. +プロバイダーと署名者オブジェクトを初期化すると、ユーザーは任意の文字列に署名できる。 ```js // add to the existing useState hook. @@ -575,9 +575,9 @@ return ( ) ``` -## Sending Native Transaction +## ネイティブ・トランザクションの送信 -You can perform native transactions, like sending KAIA from one user to another. +あるユーザーから別のユーザーへKAIAを送信するなど、ネイティブ・トランザクションを実行できる。 ```js // add to the existing useState hook. @@ -620,13 +620,13 @@ return ( ) ``` -## Working with a Smart Contract +## スマートコントラクトとの連携 -You can interact with a deployed smart contract given its Application Binary Interface(ABI) and contract address. The following steps below show how to set up and use the contract address and ABI in your project. +デプロイされたスマートコントラクトは、そのアプリケーション・バイナリ・インターフェース（ABI）とコントラクト・アドレスを指定して対話することができる。 以下のステップは、プロジェクトでコントラクトアドレスとABIを設定し、使用する方法を示しています。 -**Step 1**: Create a `constants.ts` file in the `src` root folder. +**ステップ 1**：ルートフォルダ `src` に `constants.ts` ファイルを作成する。 -Paste the following code in the newly created constants.ts file: +新しく作成したconstants.tsファイルに以下のコードを貼り付ける： ```js export const contractABI = [ @@ -672,13 +672,13 @@ export const contractABI = [ export const contractAddress = "0x3b01E4025B428fFad9481a500BAc36396719092C"; ``` -**Step 2**: Import the **contractABI** and **contractAddress** in your `etherRPC.ts` file. +**ステップ 2**：etherRPC.ts\`ファイルに**contractABI**と**contractAddress**をインポートする。 ```js -import { contractAddress, contractABI } from "./constants"; +import { contractAddress, contractABI } from "./constants"； ``` -### 1. Writing to a Contract +### 1. 契約書への書き込み ```js // add to existing useState hook @@ -713,7 +713,7 @@ return ( ) ``` -### 2. Reading from a Contract +### 2. 契約書を読む ```js // add to existing useState hook @@ -742,10 +742,10 @@ return ( ) ``` -## TroubleShooting +## トラブルシューティング -You can visit the [troubleshooting page](https://web3auth.io/docs/troubleshooting) to explore solutions to common challenges and issues from different bundlers. +トラブルシューティングページ](https://web3auth.io/docs/troubleshooting)では、様々なバンドルに共通する課題や問題の解決策を調べることができます。 -## Next Step +## 次のステップ -For more in-depth guides on Web3Auth, please refer to the [Web3Auth Docs](https://web3auth.io/docs/connect-blockchain/klaytn) and [Web3Auth Github repository](https://github.com/web3auth). +Web3Auth に関するより詳細なガイドについては、[Web3Auth Docs](https://web3auth.io/docs/connect-blockchain/klaytn) および [Web3Auth Github リポジトリ](https://github.com/web3auth) を参照してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Modal.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Modal.md index a11acb28f773..4b6f3c109485 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Modal.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Modal.md @@ -2,37 +2,37 @@ sidebar_label: Web3Modal --- -# Integrate Web3Modal into a dApp +# Web3ModalをdAppに統合する -![](/img/banners/kaia-web3Modal\\(wc\\).png) +![](/img/banners/kaia-web3Modal\(wc\).png) -## Introduction +## はじめに -[Web3Modal](https://docs.walletconnect.com/2.0/web3modal/about) is a simple-to-use library that helps developers add support for multiple providers in their dApps with a simple, customizable configuration. It makes connecting wallets, performing transactions, and managing accounts easy. +[Web3Modal](https://docs.walletconnect.com/2.0/web3modal/about)は、シンプルでカスタマイズ可能な設定で、開発者がdAppsに複数のプロバイダのサポートを追加するのを助ける、使いやすいライブラリです。 ウォレットの接続、取引の実行、アカウントの管理が簡単にできる。 -In this guide, you will use the web3Modal library to integrate multiple wallets such as Kaia Wallet, Klip, Metamask, Coinbase Wallet, etc. into your dApp built on the Kaia Network. +このガイドでは、web3Modalライブラリを使用して、Kaia Wallet、Klip、Metamask、Coinbase Walletなどの複数のウォレットをKaia Network上に構築したdAppに統合します。 -## Prerequisite +## 前提条件 -- A working react project (by executing `npx create-react-app project-name`) -- Install the necessary wallets ([Kaia Wallet](https://www.kaiawallet.io/en_US/), [Coinbase Wallet](https://www.coinbase.com/wallet/downloads), and [Metamask](https://metamask.io/download/)). -- RPC Endpoint: you can get this from one of the supported [endpoint providers](../../../../references/public-en.md). -- Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. +- 作業中のreactプロジェクト(`npx create-react-app project-name`を実行する) +- 必要なウォレット（[Kaia Wallet](https://www.kaiawallet.io/en_US/)、[Coinbase Wallet](https://www.coinbase.com/wallet/downloads)、[Metamask](https://metamask.io/download/)）をインストールします。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](../../../../references/public-en.md)の1つから取得できます。 +- [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 -## Setting up Web3Modal and Wallet Provider Options +## Web3Modalとウォレットプロバイダーのオプションを設定する -**Step 1**: Installing Web3Modal and an Ethereum library +**ステップ 1**：Web3ModalとEthereumライブラリのインストール -Install web3Modal and your preferred library for interacting with the blockchain. In this tutorial, we will be installing [@klaytn/web3modal](https://github.com/klaytn/klaytn-web3modal) which was derived from [Web3Modal](https://github.com/WalletConnect/web3modal) and modified to add Kaia Wallet and Klip wallet. Also, this tutorial will use ethers.js to interact with the Klaytn blockchain. +web3Modalと、ブロックチェーンとやりとりするためのお好みのライブラリをインストールする。 このチュートリアルでは、[Web3Modal](https://github.com/WalletConnect/web3modal)から派生した[@klaytn/web3modal](https://github.com/klaytn/klaytn-web3modal)をインストールし、Kaia WalletとKlip walletを追加するように修正します。 また、このチュートリアルでは、ethers.jsを使ってKaiaブロックチェーンとやりとりします。 ```bash npm install @klaytn/web3modal npm install --save ethers ``` -**Step 2**: Instantiating Web3Modal with wallet provider options +**ステップ 2**：ウォレットプロバイダーオプションでWeb3Modalをインスタンス化する -Install the wallet providers of your choice. Here we install Kaia Wallet, Klip and Coinbase wallet providers. +お好みのウォレットプロバイダーをインストールしてください。 ここでは、Kaia Wallet、Klip、Coinbaseのウォレットプロバイダーをインストールします。 ```bash npm install --save @coinbase/wallet-sdk @@ -40,7 +40,7 @@ npm install --save @klaytn/kaikas-web3-provider npm install --save @klaytn/klip-web3-provider ``` -In your `App.js` file, import CoinbaseWalletSDK, KaikasWeb3Provider, and KlipWeb3Provider, and instantiate the various provider options to integrate with your dapp. +あなたの`App.js`ファイルで、CoinbaseWalletSDK、KaikasWeb3Provider、KlipWeb3Providerをインポートし、あなたのdappと統合するための様々なプロバイダオプションをインスタンス化する。 ```js import CoinbaseWalletSDK from '@coinbase/wallet-sdk'; @@ -86,9 +86,9 @@ const providerOptions = { }; ``` -**Step 3**: Instantiate web3modal +**ステップ 3**：web3modalをインスタンス化する -Then, instantiate Web3Modal by passing in the provider options. +次に、プロバイダのオプションを渡してWeb3Modalをインスタンス化する。 ```js import Web3Modal from "@klaytn/web3modal"; @@ -98,9 +98,9 @@ const web3Modal = new Web3Modal( { } ) ``` -## Establishing Wallet Connection +## ウォレット接続の確立 -To establish a connection to the user’s wallet, call the `connect()` method on the Web3Modal instance. We recommend you to wrap this operation around an async function and store the retrieved provider in your state to reuse throughout the app. +ユーザーのウォレットへの接続を確立するには、Web3Modal インスタンスで `connect()` メソッドを呼び出します。 この操作を非同期関数でラップし、取得したプロバイダーをステート内に保存して、アプリ全体で再利用することを推奨する。 ```js import { ethers } from 'ethers'; @@ -134,13 +134,13 @@ function App() { ![](/img/build/tools/web3Modal.png) -## Setting up Utils function +## ユーティリティ機能の設定 -In this guide, we will be making use of the utils functions such as `truncateAddress()` and `toHex()`. The `truncateAddress()` function takes in a valid address and returns a more readable format of the address passed in. While the `toHex()` function converts numbers to hexadecimal. The following steps below show how to set up and use the utils function in your project. +このガイドでは、`truncateAddress()`や`toHex()`といったutils関数を利用する。 truncateAddress()`関数は有効なアドレスを受け取り、渡されたアドレスをより読みやすい形式で返す。 一方、`toHex()\`関数は数値を16進数に変換する。 以下のステップは、プロジェクトでutils関数をセットアップして使用する方法を示しています。 -**Step 1**: Create a `utils.js` file in the `src` root folder. +**ステップ 1**：ルートフォルダ `src` に `utils.js` ファイルを作成する。 -Paste the following code in the newly created utils.js file. +新しく作成したutils.jsファイルに以下のコードを貼り付ける。 ```js export const truncateAddress = (address) => { @@ -158,15 +158,15 @@ export const truncateAddress = (address) => { }; ``` -**Step 2**: Import the functions in your `App.js` file. +**ステップ 2**：App.js\`ファイルに関数をインポートします。 ```js import { truncateAddress, toHex } from "./utils"; ``` -## Accessing connection, account, network information +## 接続、アカウント、ネットワーク情報へのアクセス -As it is, Web3Modal does not provide built-in support for Ethereum interactions, such as retrieving connected accounts and network data. Note that to read the user’s address or connected network ID, you must directly request the information from your Ethereum library. In this guide, we’ll be getting that information using ethers.js. One way is to fetch and store this data is when connecting your user to your dapp. +このままでは、Web3Modalは、接続されたアカウントやネットワークデータを取得するようなイーサリアムのインタラクションのための組み込みサポートを提供していません。 ユーザーのアドレスや接続しているネットワークIDを読み取るには、イーサリアムライブラリから直接情報をリクエストする必要があることに注意してください。 このガイドでは、ethers.jsを使って情報を取得します。 このデータをフェッチして保存する1つの方法は、ユーザーをダップに接続するときだ。 ```js const [provider, setProvider] = useState(); @@ -202,9 +202,9 @@ return ( ); ``` -## Disconnecting Wallet +## ウォレットの切断 -Disconnecting from the wallet is achieved by using the `clearCachedProvider()` method on the web3Modal instance. Also, one good practice is to refresh the state to clear any previously stored connection data. +ウォレットからの切断は web3Modal インスタンスの `clearCachedProvider()` メソッドを使用することで達成されます。 また、以前に保存された接続データをクリアするために、ステートをリフレッシュすることも良い習慣のひとつである。 ```js function App() { @@ -229,7 +229,7 @@ const refreshState = () => { } ``` -It's important to keep in mind that the dApp state changes as users interact with it, and it's best practice to subscribe to the events that are released in response. Create useEffect hooks with subscriptions to these events so they can respond appropriately to changes. +dAppのステートはユーザーが操作することで変化することを念頭に置いておくことが重要で、それに対応してリリースされるイベントをサブスクライブするのがベストプラクティスだ。 これらのイベントへのサブスクリプションを持つ useEffect フックを作成し、変更に適切に対応できるようにします。 ```js useEffect(() => { @@ -261,9 +261,9 @@ It's important to keep in mind that the dApp state changes as users interact wit }, [provider]); ``` -## Switch Networks or Add Custom Networks +## ネットワークの切り替えまたはカスタムネットワークの追加 -As established previously, Web3Modal does not have built-in support for Ethereum interactions. In order to add or switch networks, you must directly make a request (via EIP-3085 or EIP-3326) to your Ethereum library. Here is an example of requesting to switch networks and adding the network as a fallback if it is not already present on the user’s wallet: +先に述べたように、Web3Modalはイーサリアムとのやり取りをビルトインでサポートしていない。 ネットワークを追加または切り替えるには、イーサリアムライブラリに（EIP-3085またはEIP-3326を介して）直接リクエストする必要があります。 以下は、ネットワークの切り替えを要求し、ユーザーのウォレットにそのネットワークがまだ存在しない場合、フォールバックとしてそのネットワークを追加する例である： ```js const switchNetwork = async () => { @@ -302,9 +302,9 @@ return ( ) ``` -## Signing Messages +## 署名メッセージ -Having initialised the provider and signer object, users can sign an arbitrary string. +プロバイダーと署名者オブジェクトを初期化すると、ユーザーは任意の文字列に署名できる。 ```js // add to the existing useState hook. @@ -336,7 +336,7 @@ const signMessage = async(e) => { ); ``` -## Sending Native Transaction +## ネイティブ・トランザクションの送信 You can perform native transactions, like sending KLAY from one user to another. @@ -375,11 +375,11 @@ return ( ); ``` -## Working with a smart contract +## スマートコントラクトとの連携 -With the Web3Modal provider and signer object, you can make contract interactions such as writing to and reading from a smart contract deployed to the blockchain. +Web3Modalのプロバイダと署名者オブジェクトを使えば、ブロックチェーンにデプロイされたスマートコントラクトへの書き込みや、スマートコントラクトからの読み込みといったコントラクトのやり取りができる。 -### 1. Writing to a Contract +### 1. 契約書への書き込み ```js // add to existing useState hook @@ -464,7 +464,7 @@ return ( ) ``` -### 2. Reading from a contract +### 2. 契約書を読む ```js // add to existing useState hook @@ -541,7 +541,7 @@ return ( ) ``` -## TroubleShooting +## トラブルシューティング **Node fs error, add browser \{fs: false\} to package.json** @@ -549,13 +549,13 @@ return ( Node fs error, add browser {fs: false} to package.json ``` -This occurs when you install Klip-web3-provider. To fix this issue, follow these steps: +これはKlip-web3-providerをインストールしたときに発生します。 この問題を解決するには、以下の手順に従ってください： -**Step 1**: Open up and navigate to your node_modules folder. Look for the @Klaytn/klip-web3-provider folder and navigate to it's package.json file as shown below: +**ステップ 1**：node_modulesフォルダを開いて移動します。 Kaia/klip-web3-providerフォルダを探し、以下のようにpackage.jsonファイルに移動します： > **@klaytn/klip-web3-provider/node_modules/caver-js/packages/caver.ipfs/package.json** -**Step 2**: Paste the code below in @klaytn/klip-web3-provider/node_modules/caver-js/packages/caver.ipfs/package.json file. +**ステップ 2**：以下のコードを@klaytn/klip-web3-provider/node_modules/caver-js/packages/caver.ipfs/package.jsonファイルに貼り付けます。 ```js "browser": { @@ -569,8 +569,8 @@ This occurs when you install Klip-web3-provider. To fix this issue, follow the BREAKING CHANGES: webpack<5 used to include polyfills for node.js core modules by default. ``` -This error occurs when you use webpack version 5. In this version, NodeJS polyfills is no longer supported by default. To solve this issue, refer to this [guide](https://web3auth.io/docs/troubleshooting/webpack-issues). +このエラーは webpack バージョン 5 を使用している場合に発生します。 このバージョンでは、NodeJSポリフィルはデフォルトではサポートされなくなりました。 この問題を解決するには、この[ガイド](https://web3auth.io/docs/troubleshooting/webpack-issues)を参照してください。 -## Next Step +## 次のステップ -For more in-depth guides on Web3Modal, please refer to [Web3Modal Docs](https://docs.walletconnect.com/2.0/web3modal/about) and [Web3Modal Github repository](https://github.com/klaytn/klaytn-web3modal). Also, you can find the full implementation of the code for this guide on [GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/wallet-libraries/web3Modal-sample). +Web3Modalに関するより詳細なガイドについては、[Web3Modal Docs](https://docs.walletconnect.com/2.0/web3modal/about)と[Web3Modal Githubリポジトリ](https://github.com/klaytn/klaytn-web3modal)を参照してください。 また、このガイドのコードの完全な実装は[GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/wallet-libraries/web3Modal-sample)にあります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Onboard.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Onboard.md index 1e071f0bdac2..19a536e3fdc6 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Onboard.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/web3Onboard.md @@ -2,38 +2,38 @@ sidebar_label: Web3-Onboard --- -# Integrate Web3-Onboard into a dApp +# Web3-OnboardをdAppに統合する ![](/img/banners/kaia-web3Onboard.png) -## Introduction +## はじめに -Leveraging a tool like [Web3-Onboard](https://onboard.blocknative.com/docs/overview/introduction), projects and developers may quickly integrate multiple wallets into their decentralized applications (dApps). With the help of Web3-Onboard, user onboarding has been simplified. Web3-Onboard does have different features, ranging from support for several wallets to the ability for users to connect their accounts to different chains or networks and receive real-time transaction notifications, et cetera. +Web3-Onboard](https://onboard.blocknative.com/docs/overview/introduction)のようなツールを活用することで、プロジェクトや開発者は複数のウォレットを分散型アプリケーション（dApps）に素早く統合することができる。 Web3-Onboardの助けを借りて、ユーザーのオンボーディングが簡素化されました。 Web3-Onboardには、複数のウォレットのサポートから、ユーザーが自分のアカウントを異なるチェーンやネットワークに接続し、リアルタイムの取引通知を受け取る機能など、さまざまな機能がある。 -In this guide, you will use Web3-Onboard library to integrate multiple wallets (such as Coinbase Wallet, Metamask, WalletConnect, etc.) into your dApp built on the Klaytn Network. +このガイドでは、Web3-Onboardライブラリを使用して複数のウォレット（Coinbase Wallet、Metamask、WalletConnectなど）を統合します。 をカイアネットワーク上に構築したdAppに追加することができます。 -## Prerequisite +## 前提条件 -- A working react project (by executing `npx create-react-app project-name`) -- Install the necessary wallets ([Coinbase Wallet](https://www.coinbase.com/wallet/downloads), [Metamask](https://metamask.io/download/)). -- RPC Endpoint: you can get this from one of the supported [endpoint providers](../../../../references/public-en.md). -- Test KAIA from [Faucet](https://faucet.kaia.io): fund your account with sufficient KAIA. +- 作業中のreactプロジェクト(`npx create-react-app project-name`を実行する) +- 必要なウォレット（[Coinbase Wallet](https://www.coinbase.com/wallet/downloads)、[Metamask](https://metamask.io/download/)）をインストールします。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](../../../../references/public-en.md)の1つから取得できます。 +- [Faucet](https://faucet.kaia.io)からKAIAをテスト: 口座に十分なKAIAを入金してください。 -## Getting Started +## はじめに -Web3-Onboard as a chain-agnostic wallet library, supports all EVM-compatible networks and also provides the flexibility of adding new networks to the library. In this guide, we'll use Web3-Onboard to add the Klaytn Mainnet Cypress and Klaytn Testnet Baobab to our dApp. With that said, let’s get started integrating multi-wallet compatibility using Web3-Onboard into your dApp built on Klaytn Network. +チェーンにとらわれないウォレットライブラリであるWeb3-Onboardは、すべてのEVM互換ネットワークをサポートし、ライブラリに新しいネットワークを追加する柔軟性も提供します。 このガイドでは、Web3-Onboardを使ってKaia MainnetとKaia Testnet KairosをdAppに追加します。 ということで、さっそくWeb3-Onboardを使ったマルチウォレットの互換性をKaia Networkで構築したdAppに統合してみましょう。 -## Setting up Onboard and Wallet Modules +## オンボードモジュールとウォレットモジュールのセットアップ -**Step 1**: Install @web3-onboard/core +**ステップ 1**：web3-onboard/coreをインストールする ```bash npm i @web3-onboard/core ``` -**Step 2**: Import and Instantiate Wallet Modules +**ステップ 2**：ウォレットモジュールのインポートとインスタンス化 -In this step, you can add as many wallets to be supported in your dApp using the wallet modules. But for this guide, you will add Coinbase Wallet, WalletConnect, Injected Wallets to your web3-Onboard implementation. Refer to this [docs](https://onboard.blocknative.com/docs/overview/introduction#wallet-modules) for a list of wallet modules that can be added to your dApp using Web3-Onboard. +このステップでは、ウォレットモジュールを使ってdAppでサポートするウォレットをいくつでも追加できます。 しかし、このガイドでは、Coinbase Wallet、WalletConnect、Injected Walletsをweb3-Onboardの実装に追加します。 Web3-Onboardを使用してdAppに追加できるウォレットモジュールのリストについては、こちらの[docs](https://onboard.blocknative.com/docs/overview/introduction#wallet-modules)を参照してください。 ```bash npm install @web3-onboard/coinbase // Coinbase Wallet @@ -41,7 +41,7 @@ npm install @web3-onboard/walletconnect // WalletConnect npm install @web3-onboard/injected-wallets // Used to connect to Metamask ``` -In your `App.js` file, instantiate the wallet modules to integrate with your dApp. Note that each module has its own unique options parameters to pass in, such as a fallback JSON RPC URL or default chain ID. +`App.js`ファイルで、ウォレットモジュールをインスタンス化して、dAppと統合します。 各モジュールには、フォールバックJSON RPC URLやデフォルト・チェーンIDなど、渡すべき独自のオプション・パラメータがあることに注意してください。 ```js import coinbaseWalletModule from "@web3-onboard/coinbase"; @@ -55,23 +55,23 @@ const injected = injectedModule(); const modules = [coinbaseWalletSdk, walletConnect, injected]; ``` -**Step 3**: Install and import ethers +**ステップ 3**：エーテルのインストールとインポート -The Web3-Onboard provider can be used with libraries like [ethers.js](https://docs.ethers.org/v6/) and [web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html). In this guide, we will use ethers.js to make Klaytn blockchain calls like getting the user's account, fetch balance, sign transaction, send transaction, read from and write to the smart contract. +Web3-Onboardプロバイダは、[ethers.js](https://docs.ethers.org/v6/)や[web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html)のようなライブラリで使用することができます。 このガイドでは、ethers.jsを使用して、ユーザーのアカウントの取得、残高の取得、トランザクションの署名、トランザクションの送信、スマートコントラクトからの読み取り、スマートコントラクトへの書き込みなどのKaiaブロックチェーンの呼び出しを行います。 ```bash npm install --save ethers ``` -In your `App.js` file, import the ethers package like this: +`App.js`ファイルで、ethersパッケージを次のようにインポートする： ```js import { ethers } from "ethers"; ``` -**Step 4**: Import and Setup Web3ReactProvider +**ステップ 4**：Web3ReactProviderのインポートとセットアップ -In this step, you will instantiate Onboard with the created modules and a list of chains to be compatible with the library. Open up your `App.js` file and paste the code below: +このステップでは、作成したモジュールとライブラリーと互換性のあるチェーンのリストを使ってOnboardをインスタンス化します。 `App.js`ファイルを開き、以下のコードを貼り付ける： ```js import Onboard from "@web3-onboard/core"; @@ -118,13 +118,13 @@ const onboard = Onboard({ }); ``` -## Setting up Utils function +## ユーティリティ機能の設定 -In this guide, we will be making use of the utils functions such as `truncateAddress()` and `toHex()`. The `truncateAddress()` function takes in a valid address and returns a more readable format of the address passed in. While the `toHex()` function converts numbers to hexadecimal. The following steps below show how to set up and use the utils function in your project. +このガイドでは、`truncateAddress()`や`toHex()`といったutils関数を利用する。 truncateAddress()`関数は有効なアドレスを受け取り、渡されたアドレスをより読みやすい形式で返す。 一方、`toHex()\`関数は数値を16進数に変換する。 以下のステップは、プロジェクトでutils関数をセットアップして使用する方法を示しています。 -**Step 1**: Create a `utils.js` file in the `src` root folder. +**ステップ 1**：ルートフォルダ `src` に `utils.js` ファイルを作成する。 -Paste the following code in the newly created utils.js file. +新しく作成したutils.jsファイルに以下のコードを貼り付ける。 ```js export const truncateAddress = (address) => { @@ -142,15 +142,15 @@ export const truncateAddress = (address) => { }; ``` -**Step 2**: Import the functions in your `App.js` file. +**ステップ 2**：App.js\`ファイルに関数をインポートします。 ```js import { truncateAddress, toHex } from "./utils"; ``` -## Connecting Wallet +## コネクティング・ウォレット -Inside your App function in your `App.js` file, call the `connectWallet()` method on the onboard instance to initiate the onboard popup modal. +`App.js` ファイルの App 関数内で、オンボードインスタンスの `connectWallet()` メソッドを呼び出し、オンボードポップアップモーダルを開始します。 ```js function App() { @@ -170,13 +170,13 @@ function App() { } ``` -Once you click your Connect Wallet button, you should see a modal that allows you to seamlessly connect to Coinbase Wallet and other instantiated wallets from your dApp. +Connect Wallet ボタンをクリックすると、モーダルが表示され、Coinbase Wallet やその他のインスタンス化されたウォレットに dApp からシームレスに接続できるようになります。 ![](/img/build/tools/web3-Onboard.png) -## Disconnecting Wallet +## ウォレットの切断 -Disconnecting a connected wallet can be achieved by calling the `disconnectWallet()` method on the onboard instance along with the label of the user's primary wallet. Also, one good practice is to refresh the state to clear any previously stored connection data. +接続されたウォレットを切断するには、ユーザーのプライマリウォレットのラベルと一緒にオンボードインスタンスで `disconnectWallet()` メソッドを呼び出します。 また、以前に保存された接続データをクリアするために、ステートをリフレッシュすることも良い習慣のひとつである。 ```js function App() { @@ -211,17 +211,17 @@ function App() { } ``` -## Accessing connection, account, network information +## 接続、アカウント、ネットワーク情報へのアクセス -After successfully connecting your wallet, you can use the [onboard.state.get()](https://onboard.blocknative.com/docs/modules/core#get-current-state) method to fetch the state of your connection stored through the onboard instance. You can also fetch the state during the initial connection. Now you can modify the connectWallet() method to return a list of wallet states that you can store in your state and use throughout the application. +ウォレットの接続に成功したら、[onboard.state.get()](https://onboard.blocknative.com/docs/modules/core#get-current-state) メソッドを使用して、オンボードインスタンスを通じて保存されている接続の状態を取得できます。 初回接続時に状態を取得することもできる。 これで、connectWallet() メソッドを変更して、ウォレット状態のリストを返すようにすることができます。 -**Step 1**: import React's useState +**ステップ1**：ReactのuseStateをインポートする。 ```js import { useState } from 'react'; ``` -**Step 2**: Modify code within your App function +**ステップ 2**：アプリ関数内のコードを修正する ```js function App() { @@ -259,9 +259,9 @@ function App() { } ``` -## Switching Networks +## スイッチング・ネットワーク -In order to prompt the user to switch networks in your dApps, Web3-Onboard provides a `setChain` method on an initialized instance of Onboard. Note that the target network must have been initialized with the onboard instance at the start of your application. +`dAppsでネットワークの切り替えをユーザーに促すために、Web3-Onboardは初期化されたOnboardのインスタンスに`setChain\`メソッドを提供します。 ターゲット・ネットワークは、アプリケーションの開始時にオンボード・インスタンスで初期化されていなければならないことに注意してください。 ```js const switchNetwork = async () => { @@ -275,9 +275,9 @@ return ( ) ``` -## Sending Native Transaction +## ネイティブ・トランザクションの送信 -After successfully connecting to a wallet, you can store the provider object returned from the wallet connection in a state variable as done in connectWallet() function. You can therefore use this provider and signer object to send transactions to the blockchain. +ウォレットへの接続に成功したら、connectWallet() 関数で行ったように、ウォレット接続から返されたプロバイダオブジェクトをステート変数に格納することができます。 したがって、このプロバイダーと署名者オブジェクトを使って、ブロックチェーンにトランザクションを送信することができる。 ```js // add to the existing useState hook. @@ -320,9 +320,9 @@ return ( ``` -## Interacting with Smart Contracts +## スマートコントラクトとの対話 -With the Web3-Onboard provider and signer object, you can make contract interactions such as writing to and reading from a smart contract deployed on the blockchain. +Web3-Onboardのプロバイダと署名者オブジェクトを使えば、ブロックチェーン上に配置されたスマートコントラクトへの書き込みや、スマートコントラクトからの読み込みといったコントラクトのやり取りを行うことができる。 ```js // add to existing useState hook @@ -481,7 +481,7 @@ With the Web3-Onboard provider and signer object, you can make contract interact ) ``` -## Troubleshooting +## トラブルシューティング **Polyfill node core module error** @@ -489,8 +489,8 @@ With the Web3-Onboard provider and signer object, you can make contract interact BREAKING CHANGES: webpack<5 used to include polyfills for node.js core modules by default. ``` -This error occurs when you use webpack version 5. In this version, NodeJS polyfills is no longer supported by default. To solve this issue, refer to this [guide](https://web3auth.io/docs/troubleshooting/webpack-issues). +このエラーは webpack バージョン 5 を使用している場合に発生します。 このバージョンでは、NodeJSポリフィルはデフォルトではサポートされなくなりました。 この問題を解決するには、この[ガイド](https://web3auth.io/docs/troubleshooting/webpack-issues)を参照してください。 -## Next Step +## 次のステップ -For more in-depth guides on Web3-Onboard, please refer to [Blocknative Docs](https://docs.blocknative.com/onboard) and [Blocknative Github repository](https://github.com/blocknative/onboard). Also, you can find the full implementation of the code for this guide on [GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/wallet-libraries/web3Onboard-sample). +Web3-Onboardに関するより詳細なガイドについては、[Blocknative Docs](https://docs.blocknative.com/onboard)および[Blocknative Githubリポジトリ](https://github.com/blocknative/onboard)を参照してください。 また、このガイドのコードの完全な実装は[GitHub](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/tools/wallet-libraries/web3Onboard-sample)にあります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallets.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallets.md index 50c98d9c3fd7..48135bc74f33 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallets.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tools/wallets/wallets.md @@ -1,34 +1,34 @@ -# Wallets +# 財布 -Wallets on Klaytn allows for access to accounts controlled by private keys, thus facilitating private key management, signing crypto transactions and also provides an interface to access(i.e send and receive) digital assets. This section provides a list of Klaytn supported wallets. Lets get started! +カイアのウォレットは、秘密鍵で管理されたアカウントへのアクセスを可能にし、秘密鍵の管理、暗号トランザクションへの署名を容易にし、デジタル資産へのアクセス（送受信）のインターフェースも提供します。 このセクションでは、カイアがサポートしているウォレットのリストを提供します。 始めよう！ -> **Note**: The wallets provided below are third party wallets that have integrated with Klaytn and as such it’s much advised for users to do their due diligence before using them. +> **注意**：下記のウォレットはカイアと統合されたサードパーティーウォレットです。 -| Wallet | Custody | Account Type | Platforms | Multi-sig | Browser Extension | NFT | Bridge Support | -| -------------------------------------------------- | ------------- | -------------- | ------------------------ | --------- | ----------------- | ------- | -------------- | -| [1inch](https://1inch.io/wallet/) | Non-custodial | EOA | Mobile | No | Yes | Support | No | -| [ABC Wallet](https://myabcwallet.io/en/) | Non-custodial | EOA | Mobile, Browser | No | No | Support | Yes | -| [Alpha Wallet](https://alphawallet.com/) | Non-custodial | EOA | Broswer, Mobile, API-SDK | No | No | Support | Yes | -| [Bit2Me](https://bit2me.com/suite/wallet-klaytn) | Non-custodial | EOA | Mobile, Web App | No | No | No | No | -| [BitKeep](https://bitkeep.com/) | Non-custodial | EOA | Browser, Mobile, Desktop | No | Yes | Support | Yes | -| [Biport](https://biport.io/#/) | Non-custodial | EOA | Mobile | No | No | Support | No | -| [Burrito Wallet](https://www.burritowallet.com/en) | Non-custodial | EOA | Browser, Mobile | No | Yes | Support | Yes | -| [Coin98](https://coin98.com/) | Non-custodial | EOA | Browser, Mobile, Web App | No | Yes | Support | Yes | -| [D'cent](https://dcentwallet.com/) | Hybrid | EOA | Mobile | No | No | Support | Yes | -| [DeFi Wallet](https://crypto.com/defi-wallet) | Non-custodial | EOA | Mobile, Desktop | No | No | Support | Yes | -| [DeKeys](https://www.atomrigs.io/) | Non-custodial | EOA | Browser | No | Yes | Support | No | -| [Favorlet](https://favorlet.io/) | Non-custodial | EOA | Mobile | No | No | Support | No | -| [Huobi Wallet](https://www.itoken.com/en) | Non-custodial | EOA | Mobile | No | No | Support | No | -| [Kaia Wallet](https://www.kaiawallet.io/en_US/) | Non-custodial | EOA | Mobile, Browser | No | Yes | Support | No | -| [Kaia Safe](https://safe.kaia.io/) | Non-custodial | Smart Contract | Web App | Yes | No | Support | No | -| [Klip Wallet](https://klipwallet.com/) | Non-custodial | EOA | Mobile | No | No | Support | No | -| [Krystal DeFi](https://krystal.app/) | Non-custodial | EOA | Mobile, Web App | No | No | Support | Yes | -| [Math Wallet](https://mathwallet.org/en-us/) | Custodial | EOA | Mobile, Web App, Browser | No | Yes | Support | Yes | -| [MetaMask](https://metamask.io/) | Non-custodial | EOA | Mobile, Browser | No | Yes | Support | No | -| [Midas Protocol](https://midasprotocol.io/) | Non-custodial | EOA | Mobile | No | No | Support | Yes | -| [NOW Wallet](https://walletnow.app/) | Non-custodial | EOA | Mobile, Desktop | No | No | Support | No | -| [OKX Wallet](https://www.okx.com/web3) | Non-custodial | EOA | Mobile, Browser | No | Yes | Support | Yes | -| [Rabby Wallet](https://rabby.io/) | Non-custodial | EOA | Browser, Desktop | No | Yes | Support | No | -| [Token Pocket](https://www.tokenpocket.pro/en) | Non-custodial | EOA | Mobile, Browser, API-SDK | No | Yes | Support | Yes | -| [TrustKeys](https://trustkeys.network/) | Non-custodial | EOA | Mobile | No | No | Support | No | -| [Welldone Wallet](https://welldonestudio.io/) | Non-custodial | EOA | Browser | No | Yes | No | Yes | +| 財布 | 親権 | 口座種別 | プラットフォーム | マルチシグ | ブラウザ拡張機能 | エヌエフティー | ブリッジサポート | +| -------------------------------------------------- | -------- | ------ | -------------------- | ----- | -------- | ------- | -------- | +| [1inch](https://1inch.io/wallet/) | 非監護 | イーオーエー | モバイル | いいえ | はい | サポート | いいえ | +| [ABC Wallet](https://myabcwallet.io/en/) | 非監護 | イーオーエー | モバイル, ブラウザ | いいえ | いいえ | サポート | はい | +| [Alpha Wallet](https://alphawallet.com/) | 非監護 | イーオーエー | Broswer、モバイル、API-SDK | いいえ | いいえ | サポート | はい | +| [Bit2Me](https://bit2me.com/suite/wallet-klaytn) | 非監護 | イーオーエー | モバイル、ウェブアプリ | いいえ | いいえ | いいえ | いいえ | +| [BitKeep](https://bitkeep.com/) | 非監護 | イーオーエー | ブラウザ、モバイル、デスクトップ | いいえ | はい | サポート | はい | +| [Biport](https://biport.io/#/) | 非監護 | イーオーエー | モバイル | いいえ | いいえ | サポート | いいえ | +| [Burrito Wallet](https://www.burritowallet.com/en) | 非監護 | イーオーエー | ブラウザ、モバイル | いいえ | はい | サポート | はい | +| [Coin98](https://coin98.com/) | 非監護 | イーオーエー | ブラウザ、モバイル、ウェブアプリ | いいえ | はい | サポート | はい | +| [D'cent](https://dcentwallet.com/) | ハイブリッド | イーオーエー | モバイル | いいえ | いいえ | サポート | はい | +| [DeFi Wallet](https://crypto.com/defi-wallet) | 非監護 | イーオーエー | モバイル、デスクトップ | いいえ | いいえ | サポート | はい | +| [DeKeys](https://www.atomrigs.io/) | 非監護 | イーオーエー | ブラウザ | いいえ | はい | サポート | いいえ | +| [Favorlet](https://favorlet.io/) | 非監護 | イーオーエー | モバイル | いいえ | いいえ | サポート | いいえ | +| [Huobi Wallet](https://www.itoken.com/en) | 非監護 | イーオーエー | モバイル | いいえ | いいえ | サポート | いいえ | +| [Kaia Wallet](https://www.kaiawallet.io/en_US/) | 非監護 | イーオーエー | モバイル, ブラウザ | いいえ | はい | サポート | いいえ | +| [Kaia Safe](https://safe.kaia.io/) | 非監護 | スマート契約 | ウェブアプリ | はい | いいえ | サポート | いいえ | +| [Klip Wallet](https://klipwallet.com/) | 非監護 | イーオーエー | モバイル | いいえ | いいえ | サポート | いいえ | +| [Krystal DeFi](https://krystal.app/) | 非監護 | イーオーエー | モバイル、ウェブアプリ | いいえ | いいえ | サポート | はい | +| [Math Wallet](https://mathwallet.org/en-us/) | カストーディアル | イーオーエー | モバイル、ウェブアプリ、ブラウザ | いいえ | はい | サポート | はい | +| [MetaMask](https://metamask.io/) | 非監護 | イーオーエー | モバイル, ブラウザ | いいえ | はい | サポート | いいえ | +| [Midas Protocol](https://midasprotocol.io/) | 非監護 | イーオーエー | モバイル | いいえ | いいえ | サポート | はい | +| [NOW Wallet](https://walletnow.app/) | 非監護 | イーオーエー | モバイル、デスクトップ | いいえ | いいえ | サポート | いいえ | +| [OKX Wallet](https://www.okx.com/web3) | 非監護 | イーオーエー | モバイル, ブラウザ | いいえ | はい | サポート | はい | +| [Rabby Wallet](https://rabby.io/) | 非監護 | イーオーエー | ブラウザ、デスクトップ | いいえ | はい | サポート | いいえ | +| [Token Pocket](https://www.tokenpocket.pro/en) | 非監護 | イーオーエー | モバイル、ブラウザ、API-SDK | いいえ | はい | サポート | はい | +| [TrustKeys](https://trustkeys.network/) | 非監護 | イーオーエー | モバイル | いいえ | いいえ | サポート | いいえ | +| [Welldone Wallet](https://welldonestudio.io/) | 非監護 | イーオーエー | ブラウザ | いいえ | はい | いいえ | はい | diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/basic.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/basic.md new file mode 100644 index 000000000000..c767ad7fc2e5 --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/basic.md @@ -0,0 +1,947 @@ +# ベーシック + +## TxTypeLegacyTransaction + +TxTypeLegacyTransactionは、Kaiaに以前存在したトランザクションのタイプを表す。 このトランザクション・タイプは互換性をサポートするために存在するため、[AccountKeyLegacy](../../learn/accounts.md#accountkeylegacy) に関連付けられた EOA でのみ機能する。 他のアカウント・キー・タイプに関連するEOAは、TxTypeValueTransfer、TxTypeSmartContractExecutionなどの他のトランザクション・タイプを使用すべきである。 この種の取引は、アカウントの作成、トークンの送金、スマートコントラクトの展開、スマートコントラクトの実行、または前述の組み合わせの実行が可能である。 このトランザクションタイプは以下の変更を開始する。 + +1. 送金人の残高は取引手数料分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. カイアに `to` が存在しない場合、[AccountKeyLegacy](../../learn/accounts.md#accountkeylegacy) に関連付けられた EOA が作成される。 +4. `value` KAIAは送信者から受信者に転送される。 +5. to`がnilの場合、スマートコントラクトのデプロイメントトランザクションとみなされる。 スマート・コントラクトのコードは `input\` として渡さなければならない。 +6. `to` がスマートコントラクトの場合、`input` で指定したスマートコントラクトの関数が実行される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :------- | :----------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| to | \*common.Address (Go) | 送金された金額を受け取る口座アドレス。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| v, r, s | \*big.Int (Go) | 受信者が送信者のアドレスを取得するために送信者が生成した暗号署名。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| gasPrice | \*big.Int (Go) | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの金額は `gas` ⑭ `gasPrice` によって計算される。 For example, the sender will pay 10 KLAY for a transaction fee if gas is 10 and gasPrice is 10^18. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | + +### 署名用RLPエンコーディング + +このトランザクション・タイプの署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([nonce, gasPrice, gas, to, value, input, chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +SenderTxHashRLP = encode([nonce, gasPrice, gas, to, value, input, v, r, s]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +TxHashRLP = encode([nonce, gasPrice, gas, to, value, input, v, r, s]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xe68204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a8431323334018080 +SigHash 0x40e73366650cddb7affcf5af39efa864b2c68c42b5329044fc86a12b26c4edc7 +Signature f845f84325a0b2a5a15550ec298dc7dddde3774429ed75f864c82caeb5ee24399649ad731be9a029da1014d16f2011b3307f7bbe1035b6e699a4204fc416c763def6cefd976567 +TxHashRLP 0xf8668204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a843132333425a0b2a5a15550ec298dc7dddde3774429ed75f864c82caeb5ee24399649ad731be9a029da1014d16f2011b3307f7bbe1035b6e699a4204fc416c763def6cefd976567 +TxHash e434257753bf31a130c839fec0bd34fc6ea4aa256b825288ee82db31c2ed7524 +SenderTxHashRLP 0xf8668204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a843132333425a0b2a5a15550ec298dc7dddde3774429ed75f864c82caeb5ee24399649ad731be9a029da1014d16f2011b3307f7bbe1035b6e699a4204fc416c763def6cefd976567 +SenderTxHash e434257753bf31a130c839fec0bd34fc6ea4aa256b825288ee82db31c2ed7524 + + TX(e434257753bf31a130c839fec0bd34fc6ea4aa256b825288ee82db31c2ed7524) + Contract: false + From: a94f5374fce5edbc8e2a8697c15331677e6ebf0b + To: 7b65b75d204abed71587c9e519a89277766ee1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit 0xf4240 + Value: 0xa + Data: 0x31323334 + V: 0x25 + R: 0xb2a5a15550ec298dc7dddde3774429ed75f864c82caeb5ee24399649ad731be9 + S: 0x29da1014d16f2011b3307f7bbe1035b6e699a4204fc416c763def6cefd976567 + Hex: f8668204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a843132333425a0b2a5a15550ec298dc7dddde3774429ed75f864c82caeb5ee24399649ad731be9a029da1014d16f2011b3307f7bbe1035b6e699a4204fc416c763def6cefd976567 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0xeff95d8c57d668aa274a0eaeff942ecc2cfca4c71f71ae9fdaba92735cd79b9e", + "blockNumber": "0x1", + "contractAddress": null, + "from": "0x33c97827c33d8c5e07eb263ed6ec5c229e8b4752", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x5208", + "input": "0x", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x0", + "senderTxHash": "0xff0e9a45aa8741d528baf84069cd3b52c43a51bf7cf69d896672c3c909507888", + "signatures": [ + { + "V": "0x25", + "R": "0xed8aa552324101a99792860d479cd488b7f67af0b9205968748bddcda52da6de", + "S": "0x524dbf481ea1d77c20f4d4354cc208c3149ddfa06f7ab53a03ad82d2d7fed3" + } + ], + "status": "0x1", + "to": "0xd03227635c90c7986f0e3a4e551cefbca8c55316", + "transactionHash": "0xff0e9a45aa8741d528baf84069cd3b52c43a51bf7cf69d896672c3c909507888", + "transactionIndex": "0x0", + "type": "TxTypeLegacyTransaction", + "typeInt": 0, + "value": "0x174876e800" +} +``` + +## TxType値転送 + +TxTypeValueTransfer is used when a user wants to send KLAY. Kaiaは複数のトランザクションタイプを提供し、各トランザクションタイプが単一の目的を果たすようにするため、TxTypeValueTransferはKAIAを外部所有のアカウントに送信するように制限されています。 したがって、TxTypeValueTransferは、`to`が外部所有アカウントである場合にのみ受 け入れられる。 To transfer KLAY to a smart contract account, use [TxTypeSmartContractExecution](#txtypesmartcontractexecution) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. 送金人の残高は取引手数料分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeValueTransfer のタイプ。 これは0x08でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | common.Address (Go) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +### 署名用RLPエンコーディング + +トランザクション署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、与えられたパラメータとトランザクションオブジェクトの情報を使ったRLPシリアライズの結果である： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf839b5f4088204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b018080 +SigHash 0xaa7665566c9508140bb91e36a948fc8f61c4518400a69562432d17e064f3ce43 +Signature f845f84325a0f3d0cd43661cabf53425535817c5058c27781f478cb5459874feaa462ed3a29aa06748abe186269ff10b8100a4b7d7fea274b53ea2905acbf498dc8b5ab1bf4fbc +TxHashRLP 0x08f87a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a0f3d0cd43661cabf53425535817c5058c27781f478cb5459874feaa462ed3a29aa06748abe186269ff10b8100a4b7d7fea274b53ea2905acbf498dc8b5ab1bf4fbc +TxHash 762f130342569e9669a4d8547f1248bd2554fbbf3062d63a97ce28bfa97aa9d7 +SenderTxHashRLP 0x08f87a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a0f3d0cd43661cabf53425535817c5058c27781f478cb5459874feaa462ed3a29aa06748abe186269ff10b8100a4b7d7fea274b53ea2905acbf498dc8b5ab1bf4fbc +SenderTxHash 762f130342569e9669a4d8547f1248bd2554fbbf3062d63a97ce28bfa97aa9d7 + + TX(762f130342569e9669a4d8547f1248bd2554fbbf3062d63a97ce28bfa97aa9d7) + Type: TxTypeValueTransfer + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x25","R":"0xf3d0cd43661cabf53425535817c5058c27781f478cb5459874feaa462ed3a29a","S":"0x6748abe186269ff10b8100a4b7d7fea274b53ea2905acbf498dc8b5ab1bf4fbc"}] + Hex: 08f87a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a0f3d0cd43661cabf53425535817c5058c27781f478cb5459874feaa462ed3a29aa06748abe186269ff10b8100a4b7d7fea274b53ea2905acbf498dc8b5ab1bf4fbc +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0xeff95d8c57d668aa274a0eaeff942ecc2cfca4c71f71ae9fdaba92735cd79b9e", + "blockNumber": "0x1", + "contractAddress": null, + "from": "0x33c97827c33d8c5e07eb263ed6ec5c229e8b4752", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x5208", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x1", + "senderTxHash": "0x8c18c9a609d2b22c921ce0b282e64924bf073e84f7c3850d99ec71da4054f79d", + "signatures": [ + { + "V": "0x25", + "R": "0x94e059980bce9f3ba5f09e5021ad4f32d7d9cfda938c2d38c989cd4a406e7ba", + "S": "0x3ca52ee9d23954a278e6a30f3ec40951b26fb8b3f784c236c5bb1d5c9a8b2c82" + } + ], + "status": "0x1", + "to": "0x75c3098be5e4b63fbac05838daaee378dd48098d", + "transactionHash": "0x8c18c9a609d2b22c921ce0b282e64924bf073e84f7c3850d99ec71da4054f79d", + "transactionIndex": "0x1", + "type": "TxTypeValueTransfer", + "typeInt": 8, + "value": "0x21e19e0c9bab2400000" +} +``` + +## TxType値転送メモ + +TxTypeValueTransferMemo is used when a user wants to send KLAY with a specific message. TxTypeValueTransferMemoは、`to`が外部所有口座である場合にのみ受け入れられる。 To transfer KLAY to a smart contract account, use [TxTypeSmartContractExecution](#txtypesmartcontractexecution) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. 送金人の残高は取引手数料分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeValueTransferMemo の型。 これは0x10でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | common.Address (Go) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションに付随するデータ。 メッセージはこの属性に渡されるべきである。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +### 署名用RLPエンコーディング + +トランザクション署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf841b83cf83a108204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f018080 +SigHash 0x23dd6ca2c023a152cad636ac8ed0a1a7962d3eb4cb7f3c50e34c0cc42e37d48a +Signature f845f84325a07d2b0c89ee8afa502b3186413983bfe9a31c5776f4f820210cffe44a7d568d1ca02b1cbd587c73b0f54969f6b76ef2fd95cea0c1bb79256a75df9da696278509f3 +TxHashRLP 0x10f8808204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6ff845f84325a07d2b0c89ee8afa502b3186413983bfe9a31c5776f4f820210cffe44a7d568d1ca02b1cbd587c73b0f54969f6b76ef2fd95cea0c1bb79256a75df9da696278509f3 +TxHash 6c7ee543c24e5b928b638a9f4502c1eca69103f5467ed4b6a2ed0ea5aede2e6b +SenderTxHashRLP 0x10f8808204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6ff845f84325a07d2b0c89ee8afa502b3186413983bfe9a31c5776f4f820210cffe44a7d568d1ca02b1cbd587c73b0f54969f6b76ef2fd95cea0c1bb79256a75df9da696278509f3 +SenderTxHash 6c7ee543c24e5b928b638a9f4502c1eca69103f5467ed4b6a2ed0ea5aede2e6b + + TX(6c7ee543c24e5b928b638a9f4502c1eca69103f5467ed4b6a2ed0ea5aede2e6b) + Type: TxTypeValueTransferMemo + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x25","R":"0x7d2b0c89ee8afa502b3186413983bfe9a31c5776f4f820210cffe44a7d568d1c","S":"0x2b1cbd587c73b0f54969f6b76ef2fd95cea0c1bb79256a75df9da696278509f3"}] + Data: 36383635366336633666 + Hex: 10f8808204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6ff845f84325a07d2b0c89ee8afa502b3186413983bfe9a31c5776f4f820210cffe44a7d568d1ca02b1cbd587c73b0f54969f6b76ef2fd95cea0c1bb79256a75df9da696278509f3 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x7ad6ed1f9955be00db8fb5452125f0e9a3c0856abb5b4cc4aed91ffc134321da", + "blockNumber": "0x1", + "contractAddress": null, + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x53fc", + "input": "0x68656c6c6f", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x4", + "senderTxHash": "0x7311ef305064f2a6997c16cc8b5fc3fdf301549e7b7d0baa3a995a8e79479e5e", + "signatures": [ + { + "V": "0x25", + "R": "0xd63673e1be7919e7ca42de64931c853fc568557b151e9b335df94b22de3a600f", + "S": "0x57bc916a50856b4d197f6856f16370f72f3bb0ac411b1da793fdb5bb7066966f" + } + ], + "status": "0x1", + "to": "0x75c3098be5e4b63fbac05838daaee378dd48098d", + "transactionHash": "0x7311ef305064f2a6997c16cc8b5fc3fdf301549e7b7d0baa3a995a8e79479e5e", + "transactionIndex": "0x4", + "type": "TxTypeValueTransferMemo", + "typeInt": 16, + "value": "0x989680" +} +``` + +## TxTypeSmartContractDeploy + +TxTypeSmartContractDeploy は、指定されたアドレスにスマートコントラクトをデプロイします。 このトランザクションタイプでは、以下の変更が行われる。 + +1. 送金人の残高は取引手数料分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. スマートコントラクトは `input` のコードとともにデプロイされる。 配置されたアドレスは、レシートの `contractAddress` を介して返される。 +4. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeSmartContractDeploy のタイプ。 これは0x28でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | \*common.Address (Go) | 送金された金額を受け取る口座アドレス。 現在、この値はnilでなければならない。 アドレスの指定は将来サポートされる予定。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| humanReadable | bool (Go) | 人間が読めるアドレスはまだサポートされていないので、これは偽でなければならない。 trueの場合、トランザクションは拒否される。 | +| codeFormat | uint8 (Go) | スマート・コントラクトのコード形式。 The supported value for now is EVM(0x00) only. | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +### 署名用RLPエンコーディング + +このトランザクション・タイプの署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, humanReadable, codeFormat]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, humanReadable, codeFormat, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +料金支払者のトランザクション署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, humanReadable, codeFormat, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf90240b9023af90237288204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180018080 +SigHash 0xa921fa892d5dec0837bd32c1fb77fc3b2df57ec0b0c4eea79192c79883ed543c +Signature f845f84325a0fcd107738fb47750ba727610aefd6d5f51ac8163d62ce500e7ab7e15defe7088a0383d68220d0266490ea4173c1d7847f22fcbe22f8c8125e1c0589189845c902a +TxHashRLP 0x28f9027d8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180f845f84325a0fcd107738fb47750ba727610aefd6d5f51ac8163d62ce500e7ab7e15defe7088a0383d68220d0266490ea4173c1d7847f22fcbe22f8c8125e1c0589189845c902a +TxHash e983f38b814891990f3ca57028c2230dc7e907eb313c827e7c99fadcc9b4c58b +SenderTxHashRLP 0x28f9027d8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180f845f84325a0fcd107738fb47750ba727610aefd6d5f51ac8163d62ce500e7ab7e15defe7088a0383d68220d0266490ea4173c1d7847f22fcbe22f8c8125e1c0589189845c902a +SenderTxHash e983f38b814891990f3ca57028c2230dc7e907eb313c827e7c99fadcc9b4c58b + + TX(e983f38b814891990f3ca57028c2230dc7e907eb313c827e7c99fadcc9b4c58b) + Type: TxTypeSmartContractDeploy + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x25","R":"0xfcd107738fb47750ba727610aefd6d5f51ac8163d62ce500e7ab7e15defe7088","S":"0x383d68220d0266490ea4173c1d7847f22fcbe22f8c8125e1c0589189845c902a"}] + Data: 363038303630343035323334383031353631303031303537363030303830666435623530363130316465383036313030323036303030333936303030663330303630383036303430353236303034333631303631303036313537363366666666666666663763303130303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303630303033353034313636333161333964386566383131343631303038303537383036333633353335383662313436313030613735373830363337306130383233313134363130306361353738303633666436623765663831343631303066383537356233333630303039303831353236303031363032303532363034303831323038303534333439303831303139303931353538313534303139303535303035623334383031353631303038633537363030303830666435623530363130303935363130313064353635623630343038303531393138323532353139303831393030333630323030313930663335623631303063383733666666666666666666666666666666666666666666666666666666666666666666666666666666663630303433353136363130313133353635623030356233343830313536313030643635373630303038306664356235303631303039353733666666666666666666666666666666666666666666666666666666666666666666666666666666663630303433353136363130313437353635623334383031353631303130343537363030303830666435623530363130306338363130313539353635623630303035343831353635623733666666666666666666666666666666666666666666666666666666666666666666666666666666663136363030303930383135323630303136303230353236303430383132303830353433343930383130313930393135353831353430313930353535363562363030313630323035323630303039303831353236303430393032303534383135363562333336303030393038313532363030313630323035323630343038313230383035343930383239303535393038313131313536313031616635373630343035313333393038323135363130386663303239303833393036303030383138313831383538383838663139333530353035303530313536313031396335373631303161663536356233333630303039303831353236303031363032303532363034303930323038313930353535623530353630306131363536323761376137323330353832303632376361343662623039343738613031353736323830366363303063343331323330353031313138633763323663333061633538633465303965353163346630303239 + HumanReadable: true + CodeFormat: CodeFormatEVM + Hex: 28f9027d8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180f845f84325a0fcd107738fb47750ba727610aefd6d5f51ac8163d62ce500e7ab7e15defe7088a0383d68220d0266490ea4173c1d7847f22fcbe22f8c8125e1c0589189845c902a +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "codeFormat": "0x0", + "contractAddress": "0x636f6e74726163742e6b6c6179746e0000000000", + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x0", + "gasUsed": "0xee6e343d", + "humanReadable": true, + "input": "0x608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0xa", + "senderTxHash": "0x78a5633ee5b453ed2f00937e65945a3b76e96623634e1555e2f15d44930168af", + "signatures": [ + { + "V": "0x25", + "R": "0x369d892dc24786111fd8f0308e8a6518708727257e95b3281865508faa0a768b", + "S": "0x12fc22c390a89484d1cb70e1f19c4fa8a203b1406044ee9c263264876f0dd724" + } + ], + "status": "0x1", + "to": "0x636f6e74726163742e6b6c6179746e0000000000", + "transactionHash": "0x78a5633ee5b453ed2f00937e65945a3b76e96623634e1555e2f15d44930168af", + "transactionIndex": "0x3", + "type": "TxTypeSmartContractDeploy", + "typeInt": 40, + "value": "0x0" +} +``` + +## TxTypeSmartContractExecution + +TxTypeSmartContractExecution は `input` に指定されたデータでスマートコントラクトを実行する。 TxTypeSmartContractExecution は `to` がスマートコントラクトのアカウントである場合にのみ受理される。 To transfer KLAY to an externally owned account, use [TxTypeValueTransfer](#txtypevaluetransfer) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. もし `to` がスマートコントラクトのアカウントであれば、`input` に基づいてコードが実行される。 そうでない場合、このトランザクションは拒否される。 +2. 送金人の残高は取引手数料分だけ減少する。 +3. 送信者のnonceは1増加する。 +4. `value` が提供された場合、`value` KAIA は送信者から `to` スマートコントラクトに転送される。 The contract should have a payable fallback function to receive KLAY. + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeSmartContractExecution のタイプ。 これは0x30でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | common.Address (Go) | 実行されるスマートコントラクトアカウントのアドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +### 署名用RLPエンコーディング + +このトランザクション・タイプの署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf860b85bf859308204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2018080 +SigHash 0x197ea7d262f74489934d6cbcf8baa3bec169c16ad672fef4a9f8148864c9cdce +Signature f845f84326a0e4276df1a779274fbb04bc18a0184809eec1ce9770527cebb3d64f926dc1810ba04103b828a0671a48d64fe1a3879eae229699f05a684d9c5fd939015dcdd9709b +TxHashRLP 0x30f89f8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2f845f84326a0e4276df1a779274fbb04bc18a0184809eec1ce9770527cebb3d64f926dc1810ba04103b828a0671a48d64fe1a3879eae229699f05a684d9c5fd939015dcdd9709b +TxHash 23bb192bd58d56527843eb63225c5213f3aded95e4c9776f1ff0bdd8ee0b6826 +SenderTxHashRLP 0x30f89f8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2f845f84326a0e4276df1a779274fbb04bc18a0184809eec1ce9770527cebb3d64f926dc1810ba04103b828a0671a48d64fe1a3879eae229699f05a684d9c5fd939015dcdd9709b +SenderTxHash 23bb192bd58d56527843eb63225c5213f3aded95e4c9776f1ff0bdd8ee0b6826 + + TX(23bb192bd58d56527843eb63225c5213f3aded95e4c9776f1ff0bdd8ee0b6826) + Type: TxTypeSmartContractExecution + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x26","R":"0xe4276df1a779274fbb04bc18a0184809eec1ce9770527cebb3d64f926dc1810b","S":"0x4103b828a0671a48d64fe1a3879eae229699f05a684d9c5fd939015dcdd9709b"}] + Data: 363335333538366230303030303030303030303030303030303030303030303062633539353166303535613835663431613362363266643666363861623764653736643239396232 + Hex: 30f89f8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2f845f84326a0e4276df1a779274fbb04bc18a0184809eec1ce9770527cebb3d64f926dc1810ba04103b828a0671a48d64fe1a3879eae229699f05a684d9c5fd939015dcdd9709b +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0xfedc", + "input": "0x6353586b0000000000000000000000000fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0xd", + "senderTxHash": "0xe216873dedd72d8d67a9f5e51eb5a7ed2b5f34bca334adff7a3601d6d3e2e132", + "signatures": [ + { + "V": "0x26", + "R": "0x68fe3dfd1ff3ea14427f157b5837cb6eb0b00fd0497e1c80897de1935200f0", + "S": "0x6b84fbedcb4ff785120890596fad3f797c178cda8908f3b02ee0a4442fbf4189" + } + ], + "status": "0x1", + "to": "0x636f6e74726163742e6b6c6179746e0000000000", + "transactionHash": "0xe216873dedd72d8d67a9f5e51eb5a7ed2b5f34bca334adff7a3601d6d3e2e132", + "transactionIndex": "0x6", + "type": "TxTypeSmartContractExecution", + "typeInt": 48, + "value": "0xa" +} +``` + +## TxTypeAccountUpdate + +TxTypeAccountUpdateは、指定されたアカウントのキーを更新する。 このトランザクションタイプでは、以下の変更が適用される。 + +1. 送金人の残高は取引手数料分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. アカウントのキーは `key` で更新される。 +4. このタイプのトランザクションが実行されると、その後アカウントから送信されるトランザクショ ンは新しい`key`で検証されます。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeAccountUpdate のタイプ。 これは0x20でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの金額は `gas` ⑭ `gasPrice` によって計算されます。 For example, the sender will pay 10 KLAY for a transaction fee if gas is 10 and gasPrice is 10^18. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| key | AccountKey (Go) | [AccountKey](../../learn/accounts.md#account-key)をアカウントに更新する。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +### 署名用RLPエンコーディング + +このトランザクション・タイプの署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, rlpEncodedKey]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, rlpEncodedKey, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, rlpEncodedKey, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf849b844f842208204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d018080 +SigHash 0xa0d3f1d2b4f061c3a5d9c22c7bb621aa821162b42b4db6cf1888defc2473e0ab +Signature f845f84325a0f7d479628f05f51320f0842193e3f7ae55a5b49d3645bf55c35bee1e8fd2593aa04de8eab5338fdc86e96f8c49ed516550f793fc2c4007614ce3d2a6b33cf9e451 +TxHashRLP 0x20f8888204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33df845f84325a0f7d479628f05f51320f0842193e3f7ae55a5b49d3645bf55c35bee1e8fd2593aa04de8eab5338fdc86e96f8c49ed516550f793fc2c4007614ce3d2a6b33cf9e451 +TxHash 8c70627d6b637c7d033ead083fc5e43e5cad10c704a86dd9bda7ac104a0e5ad0 +SenderTxHashRLP 0x20f8888204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33df845f84325a0f7d479628f05f51320f0842193e3f7ae55a5b49d3645bf55c35bee1e8fd2593aa04de8eab5338fdc86e96f8c49ed516550f793fc2c4007614ce3d2a6b33cf9e451 +SenderTxHash 8c70627d6b637c7d033ead083fc5e43e5cad10c704a86dd9bda7ac104a0e5ad0 + + TX(8c70627d6b637c7d033ead083fc5e43e5cad10c704a86dd9bda7ac104a0e5ad0) + Type: TxTypeAccountUpdate + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Key: AccountKeyPublic: S256Pubkey:{"x":"0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d","y":"0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3"} + Signature: [{"V":"0x25","R":"0xf7d479628f05f51320f0842193e3f7ae55a5b49d3645bf55c35bee1e8fd2593a","S":"0x4de8eab5338fdc86e96f8c49ed516550f793fc2c4007614ce3d2a6b33cf9e451"}] + Hex: 20f8888204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33df845f84325a0f7d479628f05f51320f0842193e3f7ae55a5b49d3645bf55c35bee1e8fd2593aa04de8eab5338fdc86e96f8c49ed516550f793fc2c4007614ce3d2a6b33cf9e451 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "from": "0x636f6c696e2e6b6c6179746e0000000000000000", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0xa028", + "key": "0x02a1034ef27ba4b7d1ae09b166744c5b7ee4a7a0cc5c76b2e5d74523a0a4fb56db3191", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x0", + "senderTxHash": "0x3f154903f92a179007b45b807af2d971ada9a23657e80bf5c18a75ac6516fd0b", + "signatures": [ + { + "V": "0x25", + "R": "0x757827ec43eafdc150ecb35423699ceaea41b13dd07f8620e2231a7b0e278149", + "S": "0x59d43ed3e0ed0f9d69d0c08ccca29913a8b138c000029f878f61337220a1ca1b" + } + ], + "status": "0x1", + "transactionHash": "0x3f154903f92a179007b45b807af2d971ada9a23657e80bf5c18a75ac6516fd0b", + "transactionIndex": "0x0", + "type": "TxTypeAccountUpdate", + "typeInt": 32 +} +``` + +## TxTypeCancel + +TxTypeCancelは、トランザクションプール中の同じnonceを持つトランザク ションの実行をキャンセルする。 このトランザクション・タイプは、送信されたトランザクションが一定時間未処理のように見える場合に有用である。 トランザクションが未処理と思われるケースはいくつかある：1. The transaction was lost somewhere and did not reach any of the consensus nodes. 2. トランザクションはどのコンセンサスノードでもまだ処理されていない。 3. トランザクションは処理されたが、トランザクションを含むブロックを受信していない。 + +クライアント側から、正確な理由を把握するのは非常に難しい。なぜなら、理由を把握するためには、すべてのコンセンサスノードの内部を調べる必要があるからだ。 ただし、コンセンサス・ノードに一般から接続することは禁止されている。 このような状況下で、典型的なブロックチェーンプラットフォームでは、ユーザーは古い取引と置き換えるために、より高いガス価格で別の取引を提出することが多い。 しかし、カイアではガス料金が固定されているため、古い取引を高いガス料金に置き換えることは適用されない。 + +そのトランザクションが未処理のままであれば、nonceがトランザクションの実行順序を決定するため、より高いnonceを持つ他のトランザクションは処理できない。 + +この問題を解決するために、KaiaはトランザクションタイプTxTypeCancelを提供する。 ユーザーがそのような状況に遭遇した場合、TxTypeCancelのトランザクショ ンを提出することができる。 + +上記の各状況は以下のように処理される：1. 古いトランザクションが失われた場合、このTxTypeCancelトランザクショ ンが実行され、ブロックに含まれる。 2. 古いトランザクションがまだ処理されていない場合、この TxTypeCancelは古いトランザクションを置き換える。 そして実行され、ブロックに含まれる。 3. 古いトランザクションがすでに実行されていた場合、nonceは増加し ているので、このTxTypeCancelトランザクションは低いnonceのために破棄 される。 + +TxTypeCancelトランザクションは、同じnonceを持つトランザクションを置き換え ることができる唯一のトランザクションであることに注意すること。 他のトランザクションタイプは、同じnonceを持つトランザクショ ンを置き換えることはできない。 + +このトランザクションタイプでは以下の変更が可能である。 1. 送金人の残高は取引手数料分だけ減少する。 2. 送信者のnonceは1増加する。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeCancelのタイプ。 これは0x38でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 `TxTypeCancel`トランザクションでは、この値は、キャンセルされるターゲッ トトランザクションが使用していたnonceと一致しなければならない。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +成果だ： + +1. 同じnonceを持つトランザクションがある場合、それはこのキャンセルトランザクショ ンで置き換えられる。 +2. 同じnonceがない場合、このトランザクションは通常のトランザクショ ンとして挿入される。 +3. キャンセル・トランザクションは他のトランザクション・タイプに置き換えられることはない。 + +### 署名用RLPエンコーディング + +トランザクション署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xe39fde388204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b018080 +SigHash 0xaaac6d71ad921e8a12e92c47d0b0654a20d8d9a4ff70d83f78661ccdf062ce9a +Signature f845f84325a0fb2c3d53d2f6b7bb1deb5a09f80366a5a45429cc1e3956687b075a9dcad20434a05c6187822ee23b1001e9613d29a5d6002f990498d2902904f7f259ab3358216e +TxHashRLP 0x38f8648204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a0fb2c3d53d2f6b7bb1deb5a09f80366a5a45429cc1e3956687b075a9dcad20434a05c6187822ee23b1001e9613d29a5d6002f990498d2902904f7f259ab3358216e +TxHash 10d135d590cb587cc45c1f94f4a0e3b8c24d24a6e4243f09ca395fb4e2450413 +SenderTxHashRLP 0x38f8648204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a0fb2c3d53d2f6b7bb1deb5a09f80366a5a45429cc1e3956687b075a9dcad20434a05c6187822ee23b1001e9613d29a5d6002f990498d2902904f7f259ab3358216e +SenderTxHash 10d135d590cb587cc45c1f94f4a0e3b8c24d24a6e4243f09ca395fb4e2450413 + + TX(10d135d590cb587cc45c1f94f4a0e3b8c24d24a6e4243f09ca395fb4e2450413) + Type: TxTypeCancel + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Signature: [{"V":"0x25","R":"0xfb2c3d53d2f6b7bb1deb5a09f80366a5a45429cc1e3956687b075a9dcad20434","S":"0x5c6187822ee23b1001e9613d29a5d6002f990498d2902904f7f259ab3358216e"}] + Hex: 38f8648204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a0fb2c3d53d2f6b7bb1deb5a09f80366a5a45429cc1e3956687b075a9dcad20434a05c6187822ee23b1001e9613d29a5d6002f990498d2902904f7f259ab3358216e +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x5208", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x10", + "senderTxHash": "0x0370adf89b2463d3d1fd894d6328929c931ef0cc3a8f1481affedd2e9c88d9d6", + "signatures": [ + { + "V": "0x26", + "R": "0xad73f30acfb80090cba8d3f4be4696e65f8eb7c36b85aac06a9bea350d10578f", + "S": "0x7ec2d6f052d8f916d12db2e0310381201888cb12d3a3696da80cab5195833706" + } + ], + "status": "0x1", + "transactionHash": "0x0370adf89b2463d3d1fd894d6328929c931ef0cc3a8f1481affedd2e9c88d9d6", + "transactionIndex": "0x9", + "type": "TxTypeCancel", + "typeInt": 56 +} +``` + +## TxTypeChainDataAnchoring + +TxTypeChainDataAnchoringTransactionは、サービスチェーンデータをKaiaメインチェーンにアンカーするトランザクションである。 サービスチェーンはこの種のトランザクションを定期的にKaiaメインチェーンに送信し、データの安全性と信頼性を確保します。 データ・アンカリングの詳細については、[アンカリング](../../nodes/service-chain/configure/anchoring.md)を参照のこと。 このトランザクションをRPC経由で送信することは禁じられている。 現在、この取引はセキュリティ上の理由から、プライベートなp2pチャネルを通じて実行されている。 このトランザクションは、送信者のnonceが1増加した以外は、Kaiaブロックチェーンの状態を変更しない。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeChainDataAnchoringTransaction の型。 これは0x48でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | サービスチェーンのデータ。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | + +### 署名用RLPエンコーディング + +このトランザクション・タイプの署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, anchoredData]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, anchoredData, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, anchoredData, txSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf8cfb8caf8c8488204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8a8f8a6a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405018080 +SigHash 0x07e07c69a12e384c16d94157c99d0a6fbae1d99f5d54501bfdc5937bbee7c792 +Signature f845f84325a0e58b9abf9f33a066b998fccaca711553fb4df425c9234bbb3577f9d9775bb124a02c409a6c5d92277c0a812dd0cc553d7fe1d652a807274c3786df3292cd473e09 +TxHashRLP 0x48f9010e8204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8a8f8a6a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405f845f84325a0e58b9abf9f33a066b998fccaca711553fb4df425c9234bbb3577f9d9775bb124a02c409a6c5d92277c0a812dd0cc553d7fe1d652a807274c3786df3292cd473e09 +TxHash 4aad85735e777795d24aa3eab51be959d8ebdf9683083d85b66f70b7170f2ea3 +SenderTxHashRLP 0x48f9010e8204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8a8f8a6a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405f845f84325a0e58b9abf9f33a066b998fccaca711553fb4df425c9234bbb3577f9d9775bb124a02c409a6c5d92277c0a812dd0cc553d7fe1d652a807274c3786df3292cd473e09 +SenderTxHash 4aad85735e777795d24aa3eab51be959d8ebdf9683083d85b66f70b7170f2ea3 + + TX(4aad85735e777795d24aa3eab51be959d8ebdf9683083d85b66f70b7170f2ea3) + Type: TxTypeChainDataAnchoring + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Signature: [{"V":"0x25","R":"0xe58b9abf9f33a066b998fccaca711553fb4df425c9234bbb3577f9d9775bb124","S":"0x2c409a6c5d92277c0a812dd0cc553d7fe1d652a807274c3786df3292cd473e09"}] + Hex: 48f9010e8204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8a8f8a6a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405f845f84325a0e58b9abf9f33a066b998fccaca711553fb4df425c9234bbb3577f9d9775bb124a02c409a6c5d92277c0a812dd0cc553d7fe1d652a807274c3786df3292cd473e09 + AnchoredData: f8a6a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x93a8", + "input": "0xf8a6a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x13", + "senderTxHash": "0x28b56268d18b116b08b1673caad80212f271d6e36ceef225b44c6d2a1f0413db", + "signatures": [ + { + "V": "0x26", + "R": "0x7049656869a9442d26ed0c2cbf15812dc486580d03f1cc6373104410225e1e7b", + "S": "0x3c58fd9ae9390e6484e965572821846445983d9b5eb7866aa4113c56a5bf253e" + } + ], + "status": "0x1", + "transactionHash": "0x28b56268d18b116b08b1673caad80212f271d6e36ceef225b44c6d2a1f0413db", + "transactionIndex": "0xc", + "type": "TxTypeChainDataAnchoring", + "typeInt": 72 +} +``` diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/ethereum.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/ethereum.md new file mode 100644 index 000000000000..f641f5508e9f --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/ethereum.md @@ -0,0 +1,358 @@ +# イーサリアム互換性 + +KaiaはEthereumとの互換性をサポートするためにラップされたトランザクションタイプを提供する。 Kaiaにおけるイーサリアムのトランザクションタイプは、`EthereumTxTypeEnvelope`と呼ばれる1バイトのタイプ区切り文字を除き、イーサリアムの設計と同じ属性とRLPエンコーディングスキームを持っています。 したがって、ユーザーはEthereum開発ツールで生成したトランザクションをKaia上で正常に展開することができます。 ユーザーが`eth`名前空間APIを使用する場合、タイプデリミターも省略されるため、Ethereumを使用するのと同じようにKaiaを使用することができます。 `kaia`名前空間APIを使用することで、ユーザーは既存のKaiaトランザクションタイプと混同することなく、EthereumフォーマットのトランザクションをKaiaトランザクションタイプとしてデプロイおよび取得することができる。 + +## EthereumTxTypeEnvelope + +EthereumTxTypeEnvelopeは、Ethereumのトランザクションタイプを示す生トランザクション用の1バイト接頭辞である。 Ethereumは[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)から拡張可能なトランザクション型スキームを採用しており、Kaiaと競合する型番号システムを使用している。 2つの異なるトランザクションタイプのスキーム間の衝突を解決するために、Kaiaは将来のEthereumトランザクションタイプの分離と拡張を可能にする`EthereumTxTypeEnvelope`を導入した。 + +`EthereumTxTypeEnvelope`は追加の型区切り文字であり、生のトランザクションと型番号付けにのみ使用される。 トランザクションハッシュや署名ハッシュには使用されない。 そのために、EIPs で定義されている `EthereumTransactionType` が使われる。 + +- EthereumTxTypeEnvelope: `0x78` +- TxHashRLP : EthereumTransactionType || TransactionPayload +- RawTransaction : EthereumTxTypeEnvelope || EthereumTransactionType || TransactionPayload + +## TxTypeEthereumAccessList + +`TxTypeEthereumAccessList`は[EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)で指定されたイーサリアム取引のタイプを表す。 このトランザクションタイプは、アクセスリスト、すなわち、トランザクションが アクセスすることになっているアドレスとストレージキーのリストを含む。 このトランザクション・タイプは互換性をサポートするために存在するため、[AccountKeyLegacy]に関連付けられた EOA でのみ機能する。 他のアカウント・キー・タイプに関連する EOA は、`TxTypeValueTransfer` や `TxTypeSmartContractExecution` などの他のトランザクション・タイプを使用すべきである。 このトランザクションタイプは、アカウントの作成、トークンの移転、スマートコントラクトのデプロイ/実行、または前述の混合が可能である。 + +:::note + +Kaiaネットワークは `EthTxTypeCompatibleBlock` の後にこのトランザクションタイプを処理できる。 + +::: + +:::note + +注：このトランザクションタイプはイーサリアムのトランザクションタイプのフォーマットのみをサポートする。 EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)と異なり、アクセスリストを使用することによる取引手数料のメリットはない。 + +::: + +### 属性 + +| 属性 | タイプ | 説明 | +| :--------- | :--------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | `EthereumTxTypeEnvelope` と `EthereumTransactionType` を連結した `TxTypeEthereumAccessList` 型。 これは0x7801でなければならない。 | +| chainId | \*big.Int (Go) | デスティネーションチェーンID。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの金額は `gas` ⑭ `gasPrice` によって計算される。 For example, the sender will pay 10 KLAY for a transaction fee if gas is 10 and gasPrice is 10^18. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| to | \*common.Address (Go) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| data | []byte (Go) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| accessList | type.AccessList (Go) | A list of addresses and storage keys consisting of [](common.Address, []common.Hash). | +| v, r, s | \*big.Int (Go) | 受信者が送信者のアドレスを取得するために送信者が生成した暗号署名。 | + +### 署名用RLPエンコーディング + +このトランザクションタイプの署名を作成するために、RLPのシリアライズは以下のように進められる： + +:::note + +この種のトランザクションはロンドン・シグナーで署名されるべきである。 + +::: + +```javascript +SigRLP = EthereumTransactionType || encode([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +このトランザクションタイプの `SenderTxHash` を得るために、RLPのシリアライズは以下のように進められる： + +```javascript +SenderTxHashRLP = EthereumTransactionType || encode([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, v, r, s]) +SenderTxHash = keccak256(SenderTxHashRLP) +Signature = sign(SenderTxHash, ) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクションハッシュを作成するために、RLPのシリアライゼーションは以下のように進められる： + +```javascript +TxHashRLP = EthereumTransactionType || encode([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, v, r, s]) +TxHash = keccak256(TxHashRLP) +``` + +### 未加工取引 + +```javascript +RawTx = EthereumTxTypeEnvelope || EthereumTransactionType || encode([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, v, r, s]) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript + TX(3a3ab67168de40b1f8a2141a70a4e2f551f90d7814b2fbcb3ac99ad8d8d0b641) + Contract: false + Chaind: 0x2 + From: a94f5374fce5edbc8e2a8697c15331677e6ebf0b + To: 7b65b75d204abed71587c9e519a89277766ee1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit 0xf4240 + Value: 0xa + Data: 0x31323334 + AccessList: [{0000000000000000000000000000000000000001 [0000000000000000000000000000000000000000000000000000000000000000]}] + V: 0x1 + R: 0xbfc80a874c43b71b67c68fa5927d1443407f31aef4ec6369bbecdb76fc39b0c0 + S: 0x193e62c1dd63905aee7073958675dcb45d78c716a9a286b54a496e82cb762f26 + Hex: 7801f8a1028204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a8431323334f838f7940000000000000000000000000000000000000001e1a0000000000000000000000000000000000000000000000000000000000000000001a0bfc80a874c43b71b67c68fa5927d1443407f31aef4ec6369bbecdb76fc39b0c0a0193e62c1dd63905aee7073958675dcb45d78c716a9a286b54a496e82cb762f26 + + +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +`eth_getTransactionByHash` の戻り値。 + +```javascript +{ + "blockHash": "0x7bd7e8a92ecaa5781a15a8b6fff589f8ac8a79325b517a1ba5d5f2f3d7af1b00", + "blockNumber": "0x1c8f4b", + "from": "0x5618e15ec2916bbe6cf2cce20ce31e61d6062cac", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "hash": "0x3f67e48c2090f560234f555cd4edf7853b6327aa9a6a795be1efe3f360dac118", + "input": "0x1122", + "nonce": "0x11", + "to": "0x5dce87b5bfcde54023811b168dc97a9f10913957", + "transactionIndex": "0x0", + "value": "0x186a0", + "type": "0x1", + "accessList": [ + { + "address": "0x0000000000000000000000000000000000000001", + "storageKeys": [ + "0x0000000000000000000000000000000000000000000000000000000000000000" + ] + } + ], + "chainId": "0x2710", + "v": "0x1", + "r": "0xebb2d2144293c257e27aaa1d22156f322b0d2d7385257f186c117899d791f174", + "s": "0x5cea970287c9f0f9754050a552c458c066d8f3b3e4639f561b22ce4cb7553ac0" +} +``` + +`kaia_getTransactionByHash` の戻り値 + +```javascript +{ + "accessList": [ + { + "address": "0x0000000000000000000000000000000000000001", + "storageKeys": [ + "0x0000000000000000000000000000000000000000000000000000000000000000" + ] + } + ], + "blockHash": "0x7bd7e8a92ecaa5781a15a8b6fff589f8ac8a79325b517a1ba5d5f2f3d7af1b00", + "blockNumber": "0x1c8f4b", + "chainID": "0x2710", + "from": "0x5618e15ec2916bbe6cf2cce20ce31e61d6062cac", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "hash": "0x3f67e48c2090f560234f555cd4edf7853b6327aa9a6a795be1efe3f360dac118", + "input": "0x1122", + "nonce": "0x11", + "senderTxHash": "0x3f67e48c2090f560234f555cd4edf7853b6327aa9a6a795be1efe3f360dac118", + "signatures": [ + { + "V": "0x1", + "R": "0xebb2d2144293c257e27aaa1d22156f322b0d2d7385257f186c117899d791f174", + "S": "0x5cea970287c9f0f9754050a552c458c066d8f3b3e4639f561b22ce4cb7553ac0" + } + ], + "to": "0x5dce87b5bfcde54023811b168dc97a9f10913957", + "transactionIndex": "0x0", + "type": "TxTypeEthereumAccessList", + "typeInt": 30721, + "value": "0x186a0" +} +``` + +## TxTypeEthereumDynamicFee + +`TxTypeEthereumDynamicFee` は、[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) で指定されているイーサリアム取引のタイプを表す。 この取引タイプは `gasPrice` の代わりに `gasTipCap` と `gasFeeCap` を含む。 このトランザクション・タイプは互換性をサポートするために存在するため、[AccountKeyLegacy]に関連付けられた EOA でのみ機能する。 他のアカウント・キー・タイプに関連する EOA は、`TxTypeValueTransfer` や `TxTypeSmartContractExecution` などの他のトランザクション・タイプを使用すべきである。 この種の取引は、アカウントの作成、トークンの移転、スマートコントラクトの導入/実行、または前述の混合が可能である。 + +:::note + +注: Kaia ネットワークは `EthTxTypeCompatibleBlock` の後にこのトランザクションタイプを処理できる。 + +::: + +:::note + +現在、このタイプのトランザクションはイーサリアムのトランザクションタイプのフォーマットのみをサポートしている。 EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)と異なり、アクセスリストを使用することによる取引手数料のメリットはない。 + +::: + +:::note + +注意: カイアのガス料金は固定なので、`gasTipCap`と`gasFeeCap`はそれぞれのネットワークのガス料金を取るべきである。 + +::: + +### 属性 + +| 属性 | タイプ | 説明 | +| :--------- | :--------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | `EthereumTxTypeEnvelope` と `EthereumTransactionType` を連結した `TxTypeEthereumDynamicFee` の型。 0x7802\`でなければならない。 | +| chainId | \*big.Int (Go) | デスティネーションチェーンID。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasTipCap | \*big.Int (Go) | ベースフィー(`baseFee`)に加えて送信者が支払う金額を得るための乗数。 カイアのガス料金は固定なので、`gasTipCap`と`gasFeeCap`はそれぞれのネットワークのガス料金を取る必要がある。 | +| gasFeeCap | \*big.Int (Go) | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの量は、`gas`\* `gasFeeCap` によって計算されます。 カイアのガス料金は固定なので、`gasTipCap`と`gasFeeCap`はそれぞれのネットワークのガス料金を取る必要がある。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| to | \*common.Address (Go) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| data | []byte (Go) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| accessList | type.AccessList (Go) | A list of addresses and storage keys consisting of [](common.Address, []common.Hash). | +| v, r, s | \*big.Int (Go) | 受信者が送信者のアドレスを取得するために送信者が生成した暗号署名。 | + +### 署名用RLPエンコーディング + +このトランザクションタイプの署名を作成するために、RLPのシリアライズは以下のように進められる： + +:::note + +この種のトランザクションはロンドン・シグナーで署名されるべきである。 + +::: + +```javascript +SigRLP = EthereumTransactionType || encode([chainId, nonce, gasTipCap, gasFeeCap, gasLimit, to, value, data, accessList]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +このトランザクションタイプの `SenderTxHash` を得るために、RLPのシリアライズは以下のように進められる： + +```javascript +SenderTxHashRLP = EthereumTransactionType || encode([chainId, nonce, gasTipCap, gasFeeCap, gasLimit, to, value, data, accessList, v, r, s]) +SenderTxHash = keccak256(SenderTxHashRLP) +Signature = sign(SenderTxHash, ) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクションハッシュを得るために、RLPシリアライゼーションは以下のように進められる： + +```javascript +TxHashRLP = EthereumTransactionType || encode([chainId, nonce, gasTipCap, gasFeeCap, gasLimit, to, value, data, accessList, v, r, s]) +TxHash = keccak256(TxHashRLP) +``` + +### 未加工取引 + +```javascript +RawTx = EthereumTxTypeEnvelope || EthereumTransactionType || encode([chainId, nonce, gasTipCap, gasFeeCap, gasLimit, to, value, data, accessList, v, r, s]) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript + TX(be74e122acf00c2f257e8698ecf01140b58b2880de3f24d0875730425eccb45a) + Contract: false + Chaind: 0x2 + From: a94f5374fce5edbc8e2a8697c15331677e6ebf0b + To: 7b65b75d204abed71587c9e519a89277766ee1d0 + Nonce: 1234 + GasTipCap: 0x19 + GasFeeCap: 0x19 + GasLimit 0xf4240 + Value: 0xa + Data: 0x31323334 + AccessList: [{0000000000000000000000000000000000000001 [0000000000000000000000000000000000000000000000000000000000000000]}] + V: 0x0 + R: 0xca14aa0bada2da7ca1b143c16e2dd4a69f2a1e77ce54c7f6d440fe828a777f4f + S: 0x117f0f78aed398b2995b5ee7c67ace25d52be3c72c1384c2aaa9683b351556 + Hex: 7802f8a1028204d21919830f4240947b65b75d204abed71587c9e519a89277766ee1d00a8431323334f838f7940000000000000000000000000000000000000001e1a0000000000000000000000000000000000000000000000000000000000000000080a0ca14aa0bada2da7ca1b143c16e2dd4a69f2a1e77ce54c7f6d440fe828a777f4f9f117f0f78aed398b2995b5ee7c67ace25d52be3c72c1384c2aaa9683b351556 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +`eth_getTransactionByHash` の戻り値。 + +```javascript +{ + "blockHash": "0x55792fe186e3d1515fe35a68c2c8d7977b2d7db184d80526f906c53222b77833", + "blockNumber": "0x1c944d", + "from": "0x5618e15ec2916bbe6cf2cce20ce31e61d6062cac", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "maxFeePerGas": "0x5d21dba00", + "maxPriorityFeePerGas": "0x5d21dba00", + "hash": "0x5db239963029ad9ef6c3331b10ae455638316e330b0efdae2cc1f8e86884e66e", + "input": "0x1122", + "nonce": "0x13", + "to": "0xa0f1633f4c666d7fe5ba912bd5caf03d3655ac31", + "transactionIndex": "0x0", + "value": "0x186a0", + "type": "0x2", + "accessList": [ + { + "address": "0x0000000000000000000000000000000000000001", + "storageKeys": [ + "0x0000000000000000000000000000000000000000000000000000000000000000" + ] + } + ], + "chainId": "0x2710", + "v": "0x1", + "r": "0x27e007cbe79fd8cc9b89dd798bdd5aa62d038273bf006c7c3b40e13a938ab807", + "s": "0x6209bb328855f02fa2671fecb41efd9f191b03ecab5e580227fa2a0674879384" +} +``` + +`kaia_getTransactionByHash` の戻り値 + +```javascript +{ + "accessList": [ + { + "address": "0x0000000000000000000000000000000000000001", + "storageKeys": [ + "0x0000000000000000000000000000000000000000000000000000000000000000" + ] + } + ], + "blockHash": "0x55792fe186e3d1515fe35a68c2c8d7977b2d7db184d80526f906c53222b77833", + "blockNumber": "0x1c944d", + "chainId": "0x2710", + "from": "0x5618e15ec2916bbe6cf2cce20ce31e61d6062cac", + "gas": "0x174876e800", + "hash": "0x5db239963029ad9ef6c3331b10ae455638316e330b0efdae2cc1f8e86884e66e", + "input": "0x1122", + "maxFeePerGas": "0x5d21dba00", + "maxPriorityFeePerGas": "0x5d21dba00", + "nonce": "0x13", + "senderTxHash": "0x5db239963029ad9ef6c3331b10ae455638316e330b0efdae2cc1f8e86884e66e", + "signatures": [ + { + "V": "0x1", + "R": "0x27e007cbe79fd8cc9b89dd798bdd5aa62d038273bf006c7c3b40e13a938ab807", + "S": "0x6209bb328855f02fa2671fecb41efd9f191b03ecab5e580227fa2a0674879384" + } + ], + "to": "0xa0f1633f4c666d7fe5ba912bd5caf03d3655ac31", + "transactionIndex": "0x0", + "type": "TxTypeEthereumDynamicFee", + "typeInt": 30722, + "value": "0x186a0" +} +``` diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/fee-delegation.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/fee-delegation.md new file mode 100644 index 000000000000..fb39c5467f04 --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/fee-delegation.md @@ -0,0 +1,1023 @@ +# 手数料の委任 + +## TxTypeFeeDelegatedValueTransfer + +TxTypeFeeDelegatedValueTransfer is used when a user wants to send KLAY. Kaiaは複数のトランザクションタイプを提供し、各トランザクションタイプが単一の目的を果たすようにするため、TxTypeFeeDelegatedValueTransferはKAIAを外部所有口座に送信するように制限されています。 したがって、TxTypeFeeDelegatedValueTransferは、`to`が外部所有口座である場合にのみ受理される。 To transfer KLAY to a smart contract account, use [TxTypeFeeDelegatedSmartContractExecution](#txtypefeedelegatedsmartcontractexecution) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料の分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeFeeDelegatedValueTransfer の型。 これは0x09でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | common.Address (Go) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address (Go) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([ encode([type, nonce, gasPrice, gas, to, value, from]), feePayer, chainid, 0, 0 ]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, txSignatures, feePayer, feePayerSignatures])` +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf839b5f4098204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b018080 +SigHash 0xb86e4cc0955f7c2cda1b36038c9d43a2724fc956c11e09c37625379b7eb2bd21 +Signature f845f84325a09f8e49e2ad84b0732984398749956e807e4b526c786af3c5f7416b293e638956a06bf88342092f6ff9fabe31739b2ebfa1409707ce54a54693e91a6b9bb77df0e7 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf84eb5f4098204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0x3e7c5f40e826d1d22493be59bf62928dc397de5c972bd9bfa3fe5206c24a5f82 +SignatureFeePayer f845f84326a0f45cf8d7f88c08e6b6ec0b3b562f34ca94283e4689021987abb6b0772ddfd80aa0298fe2c5aeabb6a518f4cbb5ff39631a5d88be505d3923374f65fdcf63c2955b +TxHashRLP 0x09f8d68204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a09f8e49e2ad84b0732984398749956e807e4b526c786af3c5f7416b293e638956a06bf88342092f6ff9fabe31739b2ebfa1409707ce54a54693e91a6b9bb77df0e7945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0f45cf8d7f88c08e6b6ec0b3b562f34ca94283e4689021987abb6b0772ddfd80aa0298fe2c5aeabb6a518f4cbb5ff39631a5d88be505d3923374f65fdcf63c2955b +TxHash e1e07f9971153499fc8c7bafcdaf7abc20b37aa4c18fb1e53a9bfcc259e3644c +SenderTxHashRLP 0x09f87a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a09f8e49e2ad84b0732984398749956e807e4b526c786af3c5f7416b293e638956a06bf88342092f6ff9fabe31739b2ebfa1409707ce54a54693e91a6b9bb77df0e7 +SenderTxHash 40f8c94e01e07eb5353f6cd4cd3eabd5893215dd53a50ba4b8ff9a447ac51731 + + TX(e1e07f9971153499fc8c7bafcdaf7abc20b37aa4c18fb1e53a9bfcc259e3644c) + Type: TxTypeFeeDelegatedValueTransfer + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x25","R":"0x9f8e49e2ad84b0732984398749956e807e4b526c786af3c5f7416b293e638956","S":"0x6bf88342092f6ff9fabe31739b2ebfa1409707ce54a54693e91a6b9bb77df0e7"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeePayerSig: [{"V":"0x26","R":"0xf45cf8d7f88c08e6b6ec0b3b562f34ca94283e4689021987abb6b0772ddfd80a","S":"0x298fe2c5aeabb6a518f4cbb5ff39631a5d88be505d3923374f65fdcf63c2955b"}] + Hex: 09f8d68204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84325a09f8e49e2ad84b0732984398749956e807e4b526c786af3c5f7416b293e638956a06bf88342092f6ff9fabe31739b2ebfa1409707ce54a54693e91a6b9bb77df0e7945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0f45cf8d7f88c08e6b6ec0b3b562f34ca94283e4689021987abb6b0772ddfd80aa0298fe2c5aeabb6a518f4cbb5ff39631a5d88be505d3923374f65fdcf63c2955b +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x7ad6ed1f9955be00db8fb5452125f0e9a3c0856abb5b4cc4aed91ffc134321da", + "blockNumber": "0x1", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x26", + "R": "0x984e9d43c496ef39ef2d496c8e1aee695f871e4f6cfae7f205ddda1589ca5c9e", + "S": "0x46647d1ce8755cd664f5fb4eba3082dd1a13817488029f3869662986b7b1a5ae" + } + ], + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x7918", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x2", + "senderTxHash": "0x6a8cf9a2f6d16561303445309d4f210c8be862f0d0c0e6f4998775fef9b4f957", + "signatures": [ + { + "V": "0x25", + "R": "0x368b3324b37831b51711a2eba2a7608438a2bd5956ccecbcdb07d9163ff8bc87", + "S": "0x7ee2e86ad6f01c867b2ced9d69e614ba22e539726451400fccdd56acbbc7a6f7" + } + ], + "status": "0x1", + "to": "0x75c3098be5e4b63fbac05838daaee378dd48098d", + "transactionHash": "0xea4341b5c95fd5a0c3a8a15a4177ab6394725c24f722a9e31f53474a6dcf086a", + "transactionIndex": "0x2", + "type": "TxTypeFeeDelegatedValueTransfer", + "typeInt": 9, + "value": "0x21e19e0c9bab2400000" +} +``` + +## TxTypeFeeDelegatedValueTransferMemo + +TxTypeFeeDelegatedValueTransferMemo is used when a user wants to send KLAY with a specific message. TxTypeFeeDelegatedValueTransferMemoは、`to`が外部所有口座である場合にのみ受理される。 To transfer KLAY to a smart contract account, use [TxTypeFeeDelegatedSmartContractExecution](#txtypefeedelegatedsmartcontractexecution) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料の分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | 説明 | タイプ | 値の例 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-- | +| type | uint8 (Go) | TxTypeFeeDelegatedValueTransferMemo の型。 これは0x11でなければならない。 | | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | | +| to | common.Address (Go) | 送金された金額を受け取る口座アドレス。 | | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | | +| input | \[\]byte \(Go\) | トランザクションに付随するデータ。 メッセージはこの属性に渡されるべきである。 | | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | | +| feePayer | common.Address (Go) | 料金支払者の住所。 | | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf841b83cf83a118204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f018080 +SigHash 0x3333b9336d431ffa53b795fedcf03cc2217cea3f26825ea5cbf7d69f0b99fde9 +Signature f845f84326a064e213aef0167fbd853f8f9989ef5d8b912a77457395ccf13d7f37009edd5c5ba05d0c2e55e4d8734fe2516ed56ac628b74c0eb02aa3b6eda51e1e25a1396093e1 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf856b83cf83a118204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0xed015096fb27764f576415e23576228cbf7c4fdad464ea7ffc3a1856dfe391c9 +SignatureFeePayer f845f84326a087390ac14d3c34440b6ddb7b190d3ebde1a07d9a556e5a82ce7e501f24a060f9a037badbcb12cda1ed67b12b1831683a08a3adadee2ea760a07a46bdbb856fea44 +TxHashRLP 0x11f8dc8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6ff845f84326a064e213aef0167fbd853f8f9989ef5d8b912a77457395ccf13d7f37009edd5c5ba05d0c2e55e4d8734fe2516ed56ac628b74c0eb02aa3b6eda51e1e25a1396093e1945a0043070275d9f6054307ee7348bd660849d90ff845f84326a087390ac14d3c34440b6ddb7b190d3ebde1a07d9a556e5a82ce7e501f24a060f9a037badbcb12cda1ed67b12b1831683a08a3adadee2ea760a07a46bdbb856fea44 +TxHash 8f68882f6192a53ba470aeca1e83ed9b9e519906a91256724b284dee778b21c9 +SenderTxHashRLP 0x11f8808204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6ff845f84326a064e213aef0167fbd853f8f9989ef5d8b912a77457395ccf13d7f37009edd5c5ba05d0c2e55e4d8734fe2516ed56ac628b74c0eb02aa3b6eda51e1e25a1396093e1 +SenderTxHash fffaa2b38d4e684ea70a89c78fc7b2659000d130c76ad721d68175cbfc77c550 + + TX(8f68882f6192a53ba470aeca1e83ed9b9e519906a91256724b284dee778b21c9) + Type: TxTypeFeeDelegatedValueTransferMemo + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x26","R":"0x64e213aef0167fbd853f8f9989ef5d8b912a77457395ccf13d7f37009edd5c5b","S":"0x5d0c2e55e4d8734fe2516ed56ac628b74c0eb02aa3b6eda51e1e25a1396093e1"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeePayerSig: [{"V":"0x26","R":"0x87390ac14d3c34440b6ddb7b190d3ebde1a07d9a556e5a82ce7e501f24a060f9","S":"0x37badbcb12cda1ed67b12b1831683a08a3adadee2ea760a07a46bdbb856fea44"}] + Data: 36383635366336633666 + Hex: 11f8dc8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6ff845f84326a064e213aef0167fbd853f8f9989ef5d8b912a77457395ccf13d7f37009edd5c5ba05d0c2e55e4d8734fe2516ed56ac628b74c0eb02aa3b6eda51e1e25a1396093e1945a0043070275d9f6054307ee7348bd660849d90ff845f84326a087390ac14d3c34440b6ddb7b190d3ebde1a07d9a556e5a82ce7e501f24a060f9a037badbcb12cda1ed67b12b1831683a08a3adadee2ea760a07a46bdbb856fea44 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x7ad6ed1f9955be00db8fb5452125f0e9a3c0856abb5b4cc4aed91ffc134321da", + "blockNumber": "0x1", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0xb5d80dc924c51f58eb674a142ebfd8ca1c0bc722bc85b001a5a6905ba8226b1", + "S": "0x79852418faacd4407aee4a461a08602fcf6a3a3cb63b9ba69d70ffe2f5fe3cd" + } + ], + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x7b0c", + "input": "0x68656c6c6f", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x5", + "senderTxHash": "0x5a4e42bac0b2bc8dda4ee82bfafc83e7f156f74d81d367a3db430abd40b2cd47", + "signatures": [ + { + "V": "0x26", + "R": "0xe8f5484b057b542c80f16c5bb8707e040619c3dc9ac5628d2797aa3d8a2fc0d0", + "S": "0x5d598f2f10283ded6f6e6a216f4278b27fdf4d431272fa090064ac0fd3fc8102" + } + ], + "status": "0x1", + "to": "0x75c3098be5e4b63fbac05838daaee378dd48098d", + "transactionHash": "0x66fe4d1abdf15a250f9391646e0242c8e4c3310250ca316d8fd00856aac16172", + "transactionIndex": "0x5", + "type": "TxTypeFeeDelegatedValueTransferMemo", + "typeInt": 17, + "value": "0x989680" +} +``` + +## TxTypeFeeDelegatedSmartContractDeploy + +TxTypeFeeDelegatedSmartContractDeploy は、手数料の委譲を伴うスマート・コントラクトをデプロイします。 このトランザクションタイプでは、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料の分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. スマートコントラクトは `input` のコードとともにデプロイされる。 配置されたアドレスは、レシートの `contractAddress` を介して返される。 +4. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeFeeDelegatedSmartContractDeploy の型。 これは0x29でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | \*common.Address (Go) | 送金された金額を受け取る口座アドレス。 現在、この値はnilでなければならない。 アドレスの指定は将来サポートされる予定。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| humanReadable | bool (Go) | 人間が読めるアドレスはまだサポートされていないので、これは偽でなければならない。 trueの場合、トランザクションは拒否される。 | +| codeFormat | uint8 (Go) | スマート・コントラクトのコード形式。 The supported value for now is EVM(0x00) only. | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address (Go) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, humanReadable, codeFormat]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, humanReadable, codeFormat]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input,humanReadable, codeFormat, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, humanReadable, codeFormat, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf90240b9023af90237298204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180018080 +SigHash 0xfd5e0726c763d117d07e5e688889ab7e4d0d1164d1bbca26a9d4ee629cbd875b +Signature f845f84325a04ea37b8ecfed93795a9f99b1e4d554df6fb05a361965a7655abd4e4c4422a9e5a00b05e3fffe5a3c0892eaff31466f6c47b7edad80703d395d65bbfc1a2c6a2570 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf90255b9023af90237298204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0xb7ea4d9d8c4d20ac6fd6cfffcaf89ae7d217d7450820b3b40d9ea29a0f01a1b2 +SignatureFeePayer f845f84326a0c6738376304dfb32c77649bddd4ade925b947876cfe6b1fd2c06a2e4394504cca023817ba66a6b7c92fcf23f2d5506ea2a673aae5f1a1e4d742367971ae58a1576 +TxHashRLP 0x29f902d98204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180f845f84325a04ea37b8ecfed93795a9f99b1e4d554df6fb05a361965a7655abd4e4c4422a9e5a00b05e3fffe5a3c0892eaff31466f6c47b7edad80703d395d65bbfc1a2c6a2570945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0c6738376304dfb32c77649bddd4ade925b947876cfe6b1fd2c06a2e4394504cca023817ba66a6b7c92fcf23f2d5506ea2a673aae5f1a1e4d742367971ae58a1576 +TxHash a457cc54b5cfd35eb61baa5ad61398fdcecab4c83693815addf00ca7166cb87e +SenderTxHashRLP 0x29f9027d8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180f845f84325a04ea37b8ecfed93795a9f99b1e4d554df6fb05a361965a7655abd4e4c4422a9e5a00b05e3fffe5a3c0892eaff31466f6c47b7edad80703d395d65bbfc1a2c6a2570 +SenderTxHash f3bca26fc8b50bfbcc1e94bc792ee6489cff14056e7e9aa2b074abb385f2139f + + TX(a457cc54b5cfd35eb61baa5ad61398fdcecab4c83693815addf00ca7166cb87e) + Type: TxTypeFeeDelegatedSmartContractDeploy + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Data: 363038303630343035323334383031353631303031303537363030303830666435623530363130316465383036313030323036303030333936303030663330303630383036303430353236303034333631303631303036313537363366666666666666663763303130303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303630303033353034313636333161333964386566383131343631303038303537383036333633353335383662313436313030613735373830363337306130383233313134363130306361353738303633666436623765663831343631303066383537356233333630303039303831353236303031363032303532363034303831323038303534333439303831303139303931353538313534303139303535303035623334383031353631303038633537363030303830666435623530363130303935363130313064353635623630343038303531393138323532353139303831393030333630323030313930663335623631303063383733666666666666666666666666666666666666666666666666666666666666666666666666666666663630303433353136363130313133353635623030356233343830313536313030643635373630303038306664356235303631303039353733666666666666666666666666666666666666666666666666666666666666666666666666666666663630303433353136363130313437353635623334383031353631303130343537363030303830666435623530363130306338363130313539353635623630303035343831353635623733666666666666666666666666666666666666666666666666666666666666666666666666666666663136363030303930383135323630303136303230353236303430383132303830353433343930383130313930393135353831353430313930353535363562363030313630323035323630303039303831353236303430393032303534383135363562333336303030393038313532363030313630323035323630343038313230383035343930383239303535393038313131313536313031616635373630343035313333393038323135363130386663303239303833393036303030383138313831383538383838663139333530353035303530313536313031396335373631303161663536356233333630303039303831353236303031363032303532363034303930323038313930353535623530353630306131363536323761376137323330353832303632376361343662623039343738613031353736323830366363303063343331323330353031313138633763323663333061633538633465303965353163346630303239 + HumanReadable: true + CodeFormat: CodeFormatEVM + Signature: [{"V":"0x25","R":"0x4ea37b8ecfed93795a9f99b1e4d554df6fb05a361965a7655abd4e4c4422a9e5","S":"0xb05e3fffe5a3c0892eaff31466f6c47b7edad80703d395d65bbfc1a2c6a2570"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeePayerSig: [{"V":"0x26","R":"0xc6738376304dfb32c77649bddd4ade925b947876cfe6b1fd2c06a2e4394504cc","S":"0x23817ba66a6b7c92fcf23f2d5506ea2a673aae5f1a1e4d742367971ae58a1576"}] + Hex: 29f902d98204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f00290180f845f84325a04ea37b8ecfed93795a9f99b1e4d554df6fb05a361965a7655abd4e4c4422a9e5a00b05e3fffe5a3c0892eaff31466f6c47b7edad80703d395d65bbfc1a2c6a2570945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0c6738376304dfb32c77649bddd4ade925b947876cfe6b1fd2c06a2e4394504cca023817ba66a6b7c92fcf23f2d5506ea2a673aae5f1a1e4d742367971ae58a1576 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "codeFormat": "0x0", + "contractAddress": "0x636f6e7472616374322e6b6c6179746e00000000", + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x614fd887f4702627156132c9d56584207d1eaff529ee2967431eeaba924678f9", + "S": "0x6b883a4467ca95a0ee75567062cb6d35629e9a22faeb8a711896488ce2cc4ed9" + } + ], + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x0", + "gasUsed": "0xee6e5b4d", + "humanReadable": true, + "input": "0x608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0xb", + "senderTxHash": "0xf8f83c7a4a334430f403b20d84db492fac43ebabbd9676d731e11460d01a2160", + "signatures": [ + { + "V": "0x26", + "R": "0xf3c521fea307b39bfa914b4835112bad18f89a627d639ddabe70c20af99d29a5", + "S": "0x5179048cf993049b380f8cf7017c6e83b23da7883d2728208fe6161808594f44" + } + ], + "status": "0x1", + "to": "0x636f6e7472616374322e6b6c6179746e00000000", + "transactionHash": "0x39b8a31f0c02a951615e3497d68a6534b8c8cc565e514ceafec53ee7ff50b8d9", + "transactionIndex": "0x4", + "type": "TxTypeFeeDelegatedSmartContractDeploy", + "typeInt": 41, + "value": "0x0" +} +``` + +## TxTypeFeeDelegatedSmartContractExecution + +TxTypeFeeDelegatedSmartContractExecution は `input` に指定されたデータでスマートコントラクトを実行する。 料金は所定の料金支払者が支払う。 TxTypeFeeDelegatedSmartContractExecution は `to` がスマートコントラクトアカウントである場合にのみ受理される。 To transfer KLAY to an externally owned account, use [TxTypeFeeDelegatedValueTransfer](#txtypefeedelegatedvaluetransfer) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. もし `to` がスマートコントラクトのアカウントであれば、`input` に基づいてコードが実行される。 そうでない場合、このトランザクションは拒否される。 +2. 手数料支払者の残高は、取引手数料の分だけ減少する。 +3. 送信者のnonceは1増加する。 +4. `value` が提供された場合、`value` KAIA は送信者から `to` スマートコントラクトに転送される。 The contract should have a payable fallback function to receive KLAY. + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeFeeDelegatedSmartContractExecution の型。 これは0x31でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できるガスの最大量。 | +| to | common.Address (Go) | 実行されるスマートコントラクトアカウントのアドレス。 | +| value | \*big.Int (Go) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address (Go) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf860b85bf859318204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2018080 +SigHash 0xa5dd93af9f96fa316f0ddd84f10acb2e6eb41baaec3b42f9068c38aa1618f7e1 +Signature f845f84325a0253aea7d2c37160da45e84afbb45f6b3341cf1e8fc2df4ecc78f14adb512dc4fa022465b74015c2a8f8501186bb5e200e6ce44be52e9374615a7e7e21c41bc27b5 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf875b85bf859318204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0xf547d9d0041912e0daa2db2b65170a9e833877cd8482f405a11b03429fcbd554 +SignatureFeePayer f845f84326a0e7c51db7b922c6fa2a941c9687884c593b1b13076bdf0c473538d826bf7b9d1aa05b0de2aabb84b66db8bf52d62f3d3b71b592e3748455630f1504c20073624d80 +TxHashRLP 0x31f8fb8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2f845f84325a0253aea7d2c37160da45e84afbb45f6b3341cf1e8fc2df4ecc78f14adb512dc4fa022465b74015c2a8f8501186bb5e200e6ce44be52e9374615a7e7e21c41bc27b5945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0e7c51db7b922c6fa2a941c9687884c593b1b13076bdf0c473538d826bf7b9d1aa05b0de2aabb84b66db8bf52d62f3d3b71b592e3748455630f1504c20073624d80 +TxHash ef46f28c54b3d90a183e26f406ca1d5cc2b6e9fbb6cfa7c85a10330ffadf54b0 +SenderTxHashRLP 0x31f89f8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2f845f84325a0253aea7d2c37160da45e84afbb45f6b3341cf1e8fc2df4ecc78f14adb512dc4fa022465b74015c2a8f8501186bb5e200e6ce44be52e9374615a7e7e21c41bc27b5 +SenderTxHash 3cd3380f4206943422d5d5b218dd66d03d60d19a109f9929ea12b52a230257cb + + TX(ef46f28c54b3d90a183e26f406ca1d5cc2b6e9fbb6cfa7c85a10330ffadf54b0) + Type: TxTypeFeeDelegatedSmartContractExecution + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Data: 363335333538366230303030303030303030303030303030303030303030303062633539353166303535613835663431613362363266643666363861623764653736643239396232 + Signature: [{"V":"0x25","R":"0x253aea7d2c37160da45e84afbb45f6b3341cf1e8fc2df4ecc78f14adb512dc4f","S":"0x22465b74015c2a8f8501186bb5e200e6ce44be52e9374615a7e7e21c41bc27b5"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeePayerSig: [{"V":"0x26","R":"0xe7c51db7b922c6fa2a941c9687884c593b1b13076bdf0c473538d826bf7b9d1a","S":"0x5b0de2aabb84b66db8bf52d62f3d3b71b592e3748455630f1504c20073624d80"}] + Hex: 31f8fb8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b2f845f84325a0253aea7d2c37160da45e84afbb45f6b3341cf1e8fc2df4ecc78f14adb512dc4fa022465b74015c2a8f8501186bb5e200e6ce44be52e9374615a7e7e21c41bc27b5945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0e7c51db7b922c6fa2a941c9687884c593b1b13076bdf0c473538d826bf7b9d1aa05b0de2aabb84b66db8bf52d62f3d3b71b592e3748455630f1504c20073624d80 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x1c7de2c83542b623ba47722f310c0e5893486eef4eed70b634d456262fb430a7", + "S": "0x177929c52669c4b9433565a76e53723b702bae8142debe1981062f59f25062ab" + } + ], + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x0", + "gasUsed": "0xb0bc", + "input": "0x6353586b0000000000000000000000000fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0xe", + "senderTxHash": "0xffd354e4e271ff94a7459c2f1bc0df20dc112a83f5625ff7e31d196444f72710", + "signatures": [ + { + "V": "0x25", + "R": "0xefc6fec3dae47a08941712f637c95dbc46ef2afd3d16e68da602a878c0bba047", + "S": "0x938a5374edcea0503df8e7af906a7642f7e935eab7c489b7ca8b976a8e5ab7e" + } + ], + "status": "0x1", + "to": "0x636f6e74726163742e6b6c6179746e0000000000", + "transactionHash": "0x658a118112ffb0c06adecd59b0f11b58cf7d8afd7ec5e5d323cfca021c3dcb37", + "transactionIndex": "0x7", + "type": "TxTypeFeeDelegatedSmartContractExecution", + "typeInt": 49, + "value": "0xa" +} +``` + +## TxTypeFeeDelegatedAccountUpdate + +TxTypeFeeDelegatedAccountUpdate は、指定された口座のキーを更新します。 取引手数料は手数料支払者が支払う。 このトランザクションタイプによって、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料の分だけ減少する。 +2. 送信者のnonceは1増加する。 +3. アカウントのキーは `key` で更新される。 +4. このタイプのトランザクションが実行されると、その後アカウントから送信されるトランザクショ ンは新しい`key`で検証されます。 +5. 取引手数料は手数料支払者が支払う。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeAccountUpdate のタイプ。 これは0x21でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの金額は `gas` ⑭ `gasPrice` によって計算される。 For example, the sender will pay 10 KLAY for a transaction fee if gas is 10 and gasPrice is 10^18. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| key | AccountKey (Go) | [AccountKey](../../learn/accounts.md#account-key)をアカウントに更新する。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address (Go) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, rlpEncodedKey]), chainid, 0, 0])` +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, from, rlpEncodedKey]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, rlpEncodedKey, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, rlpEncodedKey, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf849b844f842218204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d018080 +SigHash 0x78437953e6beb985ea3ccbee8d6a648a09d11249389477a32c7094fc7b8765ef +Signature f845f84326a0ab69d9adca15d9763c4ce6f98b35256717c6e932007658f19c5a255de9e70ddaa026aa676a3a1a6e96aff4a3df2335788d614d54fb4db1c3c48551ce1fa7ac5e52 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf85eb844f842218204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0x1026d3ac74f56b52453d656b084d06798479b8bcfda1868d8beaa23e36f3aeb3 +SignatureFeePayer f845f84326a0f295cd69b4144d9dbc906ba144933d2cc535d9d559f7a92b4672cc5485bf3a60a0784b8060234ffd64739b5fc2f2503939340ab4248feaa6efcf62cb874345fe40 +TxHashRLP 0x21f8e48204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33df845f84326a0ab69d9adca15d9763c4ce6f98b35256717c6e932007658f19c5a255de9e70ddaa026aa676a3a1a6e96aff4a3df2335788d614d54fb4db1c3c48551ce1fa7ac5e52945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0f295cd69b4144d9dbc906ba144933d2cc535d9d559f7a92b4672cc5485bf3a60a0784b8060234ffd64739b5fc2f2503939340ab4248feaa6efcf62cb874345fe40 +TxHash 756ff5d3912a4089659614d42a218eee59e602a5992bddca383c2d295c6637bb +SenderTxHashRLP 0x21f8888204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33df845f84326a0ab69d9adca15d9763c4ce6f98b35256717c6e932007658f19c5a255de9e70ddaa026aa676a3a1a6e96aff4a3df2335788d614d54fb4db1c3c48551ce1fa7ac5e52 +SenderTxHash f56937017bd3b75c637ba5b4ce90df20c166006a2a529b42e808bc806159b98f + + TX(756ff5d3912a4089659614d42a218eee59e602a5992bddca383c2d295c6637bb) + Type: TxTypeFeeDelegatedAccountUpdate + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Key: AccountKeyPublic: S256Pubkey:{"x":"0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d","y":"0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3"} + Signature: [{"V":"0x26","R":"0xab69d9adca15d9763c4ce6f98b35256717c6e932007658f19c5a255de9e70dda","S":"0x26aa676a3a1a6e96aff4a3df2335788d614d54fb4db1c3c48551ce1fa7ac5e52"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeePayerSig: [{"V":"0x26","R":"0xf295cd69b4144d9dbc906ba144933d2cc535d9d559f7a92b4672cc5485bf3a60","S":"0x784b8060234ffd64739b5fc2f2503939340ab4248feaa6efcf62cb874345fe40"}] + Hex: 21f8e48204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33df845f84326a0ab69d9adca15d9763c4ce6f98b35256717c6e932007658f19c5a255de9e70ddaa026aa676a3a1a6e96aff4a3df2335788d614d54fb4db1c3c48551ce1fa7ac5e52945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0f295cd69b4144d9dbc906ba144933d2cc535d9d559f7a92b4672cc5485bf3a60a0784b8060234ffd64739b5fc2f2503939340ab4248feaa6efcf62cb874345fe40 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x3b019642e5ae37f3ecbf85e6fc1ee77e51d1618299367bcedd816d0da6afb1e0", + "S": "0x5c12c87811a74183f8b56b707fa90a916b1c641652c93e52300f5cee36141d73" + } + ], + "from": "0x636f6c696e322e6b6c6179746e00000000000000", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0xc738", + "key": "0x02a1034ef27ba4b7d1ae09b166744c5b7ee4a7a0cc5c76b2e5d74523a0a4fb56db3191", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x0", + "senderTxHash": "0xf4e7ef082451d4a3c8ad7c4348fc99c965a9c130bfc98d7971f3103e3dcfda3c", + "signatures": [ + { + "V": "0x26", + "R": "0xd4cb16abcdf92969dc45efacaa5827ad55738fbda08a3dbaf0f0553643084a6", + "S": "0x23f8055933b416cf15568a017e0a11e0a5c0a8f65477f6ec71de0bf837f4a681" + } + ], + "status": "0x1", + "transactionHash": "0xeb0c14d903db38deee116ac8a0d620e6ca6aa79e4f91393abbddfa30810b9d43", + "transactionIndex": "0x2", + "type": "TxTypeFeeDelegatedAccountUpdate", + "typeInt": 33 +}, +``` + +## TxTypeFeeDelegatedCancel + +TxTypeFeeDelegatedCancelは、トランザクションプール中の同じnonceを持つトランザク ションの実行をキャンセルする。 詳細については、[TxTypeCancel](./basic.md#txtypecancel) を参照のこと。 + +このトランザクションタイプでは、以下の変更が適用される。 1. 手数料支払者の残高は、取引手数料の分だけ減少する。 2. 送信者のnonceは1増加する。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeCancelのタイプ。 これは0x39でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address (Go) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, from]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xe39fde398204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b018080 +SigHash 0xd36c4277f4aa1d483a5fc4d656aeea50416c28adddb27a234d320290bd2a343c +Signature f845f84326a08409f5441d4725f90905ad87f03793857d124de7a43169bc67320cd2f020efa9a060af63e87bdc565d7f7de906916b2334336ee7b24d9a71c9521a67df02e7ec92 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf8389fde398204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0x15859ecc06acbd2dd5820c5968a85590826d1f6affb938e89559558ac4f86a24 +SignatureFeePayer f845f84326a0044d5b25e8c649a1fdaa409dc3817be390ad90a17c25bc17c89b6d5d248495e0a073938e690d27b5267c73108352cf12d01de7fd0077b388e94721aa1fa32f85ec +TxHashRLP 0x39f8c08204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84326a08409f5441d4725f90905ad87f03793857d124de7a43169bc67320cd2f020efa9a060af63e87bdc565d7f7de906916b2334336ee7b24d9a71c9521a67df02e7ec92945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0044d5b25e8c649a1fdaa409dc3817be390ad90a17c25bc17c89b6d5d248495e0a073938e690d27b5267c73108352cf12d01de7fd0077b388e94721aa1fa32f85ec +TxHash 96b39d3ab849127d31a5f7b5c882ca9ba408cd9d875052640d51a64f8c4acbb2 +SenderTxHashRLP 0x39f8648204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84326a08409f5441d4725f90905ad87f03793857d124de7a43169bc67320cd2f020efa9a060af63e87bdc565d7f7de906916b2334336ee7b24d9a71c9521a67df02e7ec92 +SenderTxHash cc6c2673398903b3d906a3023b41636fc08bd1bddd5aa1602116091638f48447 + + TX(96b39d3ab849127d31a5f7b5c882ca9ba408cd9d875052640d51a64f8c4acbb2) + Type: TxTypeFeeDelegatedCancel + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Signature: [{"V":"0x26","R":"0x8409f5441d4725f90905ad87f03793857d124de7a43169bc67320cd2f020efa9","S":"0x60af63e87bdc565d7f7de906916b2334336ee7b24d9a71c9521a67df02e7ec92"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeePayerSig: [{"V":"0x26","R":"0x44d5b25e8c649a1fdaa409dc3817be390ad90a17c25bc17c89b6d5d248495e0","S":"0x73938e690d27b5267c73108352cf12d01de7fd0077b388e94721aa1fa32f85ec"}] + Hex: 39f8c08204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0bf845f84326a08409f5441d4725f90905ad87f03793857d124de7a43169bc67320cd2f020efa9a060af63e87bdc565d7f7de906916b2334336ee7b24d9a71c9521a67df02e7ec92945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0044d5b25e8c649a1fdaa409dc3817be390ad90a17c25bc17c89b6d5d248495e0a073938e690d27b5267c73108352cf12d01de7fd0077b388e94721aa1fa32f85ec +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x26a7c88e1fc77400f2a4c7911966a5e51b0873e3f26daf9d6519b93e3f3db6a3", + "S": "0x560e5fa8d53ebf899eb48353bf14794c76784240a6a212f5ddbe7f1684088f3f" + } + ], + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x7918", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x11", + "senderTxHash": "0x2fea0ff37b8b936d4c06f29b98c4bd200827423fb445f931eb64725aefcda053", + "signatures": [ + { + "V": "0x26", + "R": "0xcfdb5b3ff6c87a8f18ae606b371d1e569c56d35a737831b89052c5a8ef19d049", + "S": "0x1ee63bd5a01c45d0c6f1b36a29e1c01b56baa719f008c556bc9054ac5a64bd8d" + } + ], + "status": "0x1", + "transactionHash": "0xf475e714b30aef0b79d46c9482289f3fbe51f1e44bcbc99a90ac8e25672bc969", + "transactionIndex": "0xa", + "type": "TxTypeFeeDelegatedCancel", + "typeInt": 57 +} +``` + +## TxTypeFeeDelegatedChainDataAnchoring + +TxTypeFeeDelegatedChainDataAnchoringは、サービスチェーンデータをカイアメインチェーンにアンカーする、手数料委任トランザクションである。 サービスチェーンはこの種のトランザクションを定期的にKaiaメインチェーンに送信し、データの安全性と信頼性を確保します。 データ・アンカリングの詳細については、[アンカリング](../../nodes/service-chain/configure/anchoring.md)を参照のこと。 この取引もまた、フィー委任取引であるため、その取引手数料はフィー支払者に請求される。 このトランザクションをRPC経由で送信することは禁じられている。 現在、この取引はセキュリティ上の理由から、プライベートなp2pチャネルを通じて実行されている。 このトランザクションは、送信者のnonceが1増加した以外は、Kaiaブロックチェーンの状態を変更しない。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 (Go) | TxTypeFeeDelegatedChainDataAnchoring の型。 これは0x49でなければならない。 | +| nonce | uint64 (Go) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int (Go) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 (Go) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address (Go) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | サービスチェーンのデータ。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address (Go) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, anchoredData]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, from, anchoredData]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, anchoredData, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, anchoredData, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x01 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf8dbb8d6f8d449118505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006018080 +SigHash 0x92e385b4a162170ee87b2b2e598f686b1d16f385d98ad626147305624abec0b3 +Signature 0xf845f84326a0afe41edc9cce1185ab9065ca7dbfb89ab5c7bde3602a659aa258324124644142a0317848698248ba7cc057b8f0dd19a27b52ef904d29cb72823100f1ed18ba2bb3 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf8f0b8d6f8d449118505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a000000000000000000000000000000000000000000000000000000000000000040580069433f524631e573329a550296f595c820d6c65213f018080 +SigHashFeePayer 0x4d58fdf276fde1e221b6bab8c6621ae1639b00a7a70d2bd0a114001692a3a7d1 +SignatureFeePayer 0xf845f84325a0309e46db21a1bf7bfdae24d9192aca69516d6a341ecce8971fc69cff481cee76a04b939bf7384c4f919880307323a5e36d4d6e029bae1887a43332710cdd48f174 +TxHashRLP 0x49f90176118505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006f845f84326a0afe41edc9cce1185ab9065ca7dbfb89ab5c7bde3602a659aa258324124644142a0317848698248ba7cc057b8f0dd19a27b52ef904d29cb72823100f1ed18ba2bb39433f524631e573329a550296f595c820d6c65213ff845f84325a0309e46db21a1bf7bfdae24d9192aca69516d6a341ecce8971fc69cff481cee76a04b939bf7384c4f919880307323a5e36d4d6e029bae1887a43332710cdd48f174 +TxHash 0xecf1ec12937065617f9b3cd07570452bfdb75dc36404c4f37f78995c6dc462af +SenderTxHashRLP 0x49f9011a118505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006f845f84326a0afe41edc9cce1185ab9065ca7dbfb89ab5c7bde3602a659aa258324124644142a0317848698248ba7cc057b8f0dd19a27b52ef904d29cb72823100f1ed18ba2bb3 +SenderTxHash 0x4f5c00ea8f6346baa7d4400dfefd72efa5ec219561ebcebed7be8a2b79d52bcd + + TX(ecf1ec12937065617f9b3cd07570452bfdb75dc36404c4f37f78995c6dc462af) + Type: TxTypeFeeDelegatedChainDataAnchoring + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 17 + GasPrice: 0x5d21dba00 + GasLimit: 0x174876e800 + AnchoredData: f8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006 + Signature: [{"V":"0x26","R":"0xafe41edc9cce1185ab9065ca7dbfb89ab5c7bde3602a659aa258324124644142","S":"0x317848698248ba7cc057b8f0dd19a27b52ef904d29cb72823100f1ed18ba2bb3"}] + FeePayer: 0x33f524631e573329a550296F595c820D6c65213f + FeePayerSig: [{"V":"0x25","R":"0x309e46db21a1bf7bfdae24d9192aca69516d6a341ecce8971fc69cff481cee76","S":"0x4b939bf7384c4f919880307323a5e36d4d6e029bae1887a43332710cdd48f174"}] + Hex: 49f90176118505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006f845f84326a0afe41edc9cce1185ab9065ca7dbfb89ab5c7bde3602a659aa258324124644142a0317848698248ba7cc057b8f0dd19a27b52ef904d29cb72823100f1ed18ba2bb39433f524631e573329a550296f595c820d6c65213ff845f84325a0309e46db21a1bf7bfdae24d9192aca69516d6a341ecce8971fc69cff481cee76a04b939bf7384c4f919880307323a5e36d4d6e029bae1887a43332710cdd48f174 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x170a32e16b6fdced144d5104f5aecf753878bd9f1a7d87ddccc2e6d2ba27354c", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x33f524631e573329a550296f595c820d6c65213f", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x309e46db21a1bf7bfdae24d9192aca69516d6a341ecce8971fc69cff481cee76", + "S": "0x4b939bf7384c4f919880307323a5e36d4d6e029bae1887a43332710cdd48f174" + } + ], + "from": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0xbd74", + "input": "0xf8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x11", + "senderTxHash": "0x4f5c00ea8f6346baa7d4400dfefd72efa5ec219561ebcebed7be8a2b79d52bcd", + "signatures": [ + { + "V": "0x26", + "R": "0xafe41edc9cce1185ab9065ca7dbfb89ab5c7bde3602a659aa258324124644142", + "S": "0x317848698248ba7cc057b8f0dd19a27b52ef904d29cb72823100f1ed18ba2bb3" + } + ], + "status": "0x1", + "transactionHash": "0xecf1ec12937065617f9b3cd07570452bfdb75dc36404c4f37f78995c6dc462af", + "transactionIndex": "0xa", + "type": "TxTypeFeeDelegatedChainDataAnchoring", + "typeInt": 73 +} +``` diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/partial-fee-delegation.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/partial-fee-delegation.md new file mode 100644 index 000000000000..df5782e88d76 --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/partial-fee-delegation.md @@ -0,0 +1,1051 @@ +# 料金の一部委任 + +## TxTypeFeeDelegatedValueTransferWithRatio + +TxTypeFeeDelegatedValueTransferWithRatio is used when a user wants to send KLAY. カイアは、各トランザクションタイプが単一の目的を果たすように、複数のトランザクションタイプを提供するため、TxTipeFeyDelegatedValueTransferWithRatioは、KAIAを外部所有口座に送信するように制限されています。 したがって、TxTypeFeeDelegatedValueTransferWithRatioは、`to`が外部所有口座である場合にのみ受け入れられる。 To transfer KLAY to a smart contract account, use [TxTypeFeeDelegatedSmartContractExecutionWithRatio](#txtypefeedelegatedsmartcontractexecutionwithratio) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料の所定の比率だけ減少する。 +2. 送信者の残高は、残りの取引手数料分だけ減少する。 例えば、`feeRatio`が30であれば、手数料の30%は手数料を支払う側が支払い、残りの70%は手数料を支払う側が支払うことになります。 +3. 送信者のnonceは1増加する。 +4. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedValueTransferWithRatio の型。 これは0x0aでなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できるガスの最大量。 | +| to | common.Address \(Go\) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int \(Go\) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, feeRatio]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, feeRatio]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, feeRatio, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, feeRatio, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf83ab6f50a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b1e018080 +SigHash 0x0f7d520cd00034299b36004c21b571263dbb9a77edbd5920c4136f7f74050d9d +Signature f845f84325a0dde32b8241f039a82b124fe94d3e556eb08f0d6f26d07dcc0f3fca621f1090caa01c8c336b358ab6d3a2bbf25de2adab4d01b754e2fb3b9b710069177d54c1e956 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf84fb6f50a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b1e945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0x38123c30a5f83db853e9ae4e8dd8d4f6aa6840415acffb8dbf18b2050463dec4 +SignatureFeePayer f845f84326a0091ecf53f91bb97bb694f2f2443f3563ac2b646d651497774524394aae396360a044228b88f275aa1ec1bab43681d21dc7e3a676786ed1906f6841d0a1a188f88a +TxHashRLP 0x0af8d78204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84325a0dde32b8241f039a82b124fe94d3e556eb08f0d6f26d07dcc0f3fca621f1090caa01c8c336b358ab6d3a2bbf25de2adab4d01b754e2fb3b9b710069177d54c1e956945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0091ecf53f91bb97bb694f2f2443f3563ac2b646d651497774524394aae396360a044228b88f275aa1ec1bab43681d21dc7e3a676786ed1906f6841d0a1a188f88a +TxHash 83a89f4debd8e9d6374b987e25132b3a4030c9cf9ace2fc6e7d1086fcea2ce40 +SenderTxHashRLP 0x0af87b8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84325a0dde32b8241f039a82b124fe94d3e556eb08f0d6f26d07dcc0f3fca621f1090caa01c8c336b358ab6d3a2bbf25de2adab4d01b754e2fb3b9b710069177d54c1e956 +SenderTxHash 4711ed4023e821425968342c1d50063b6bc3176b1792b7075cfeee3656d450f6 + + TX(83a89f4debd8e9d6374b987e25132b3a4030c9cf9ace2fc6e7d1086fcea2ce40) + Type: TxTypeFeeDelegatedValueTransferWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x25","R":"0xdde32b8241f039a82b124fe94d3e556eb08f0d6f26d07dcc0f3fca621f1090ca","S":"0x1c8c336b358ab6d3a2bbf25de2adab4d01b754e2fb3b9b710069177d54c1e956"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeeRatio: 30 + FeePayerSig: [{"V":"0x26","R":"0x91ecf53f91bb97bb694f2f2443f3563ac2b646d651497774524394aae396360","S":"0x44228b88f275aa1ec1bab43681d21dc7e3a676786ed1906f6841d0a1a188f88a"}] + Hex: 0af8d78204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84325a0dde32b8241f039a82b124fe94d3e556eb08f0d6f26d07dcc0f3fca621f1090caa01c8c336b358ab6d3a2bbf25de2adab4d01b754e2fb3b9b710069177d54c1e956945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0091ecf53f91bb97bb694f2f2443f3563ac2b646d651497774524394aae396360a044228b88f275aa1ec1bab43681d21dc7e3a676786ed1906f6841d0a1a188f88a +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x7ad6ed1f9955be00db8fb5452125f0e9a3c0856abb5b4cc4aed91ffc134321da", + "blockNumber": "0x1", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0xb8583f638efefb297922aa8b8a30cf451a30e266126d52da03ba9ead0fbb1ccd", + "S": "0x4bc5ca3756f88d857d115b128b00babe5b3c0b089f087a0b30a9ced269e00603" + } + ], + "feeRatio": "0x14", + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x8ca0", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x3", + "senderTxHash": "0xac372c68d2937383d4344a2d187e70b207c76160eb407b68e08c944b919328de", + "signatures": [ + { + "V": "0x26", + "R": "0x1a8d5bf583843ceba87943569a34a8a6caa18a9ab5e4cf6914d8048e607787bc", + "S": "0x27458275c84adcb8144b4596946111f1a539643941de74f587fa69a7df98ed1b" + } + ], + "status": "0x1", + "to": "0x75c3098be5e4b63fbac05838daaee378dd48098d", + "transactionHash": "0x670ff613022278cc2551a7e4669d8911f1658ffaa4dcc3695b14f39194a8a38c", + "transactionIndex": "0x3", + "type": "TxTypeFeeDelegatedValueTransferWithRatio", + "typeInt": 10, + "value": "0x989680" +} +``` + +## TxTypeFeeDelegatedValueTransferMemoWithRatio + +TxTypeFeeDelegatedValueTransferMemoWithRatio is used when a user wants to send KLAY with a specific message. TxTypeFeeDelegatedValueTransferMemoWithRatio は `to` が外部所有口座である場合にのみ受理される。 To transfer KLAY to a smart contract account, use [TxTypeFeeDelegatedSmartContractExecutionWithRatio](#txtypefeedelegatedsmartcontractexecutionwithratio) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料額の手数料率分だけ減少する。 +2. 送信者の残高は、残りの取引手数料分だけ減少する。 例えば、`feeRatio`が30の場合、料金の30%は料金支払者が支払い、残りの70%は料金送信者が支払う。 +3. 送信者のnonceは1増加する。 +4. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | 説明 | タイプ | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedValueTransferMemoWithRatio の型。 これは0x12でなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できるガスの最大量。 | +| to | common.Address \(Go\) | 送金された金額を受け取る口座アドレス。 | +| value | \*big.Int \(Go\) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションに付随するデータ。 メッセージはこの属性に渡されるべきである。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, feeRatio]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, feeRatio]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, feeRatio, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, feeRatio, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf842b83df83b128204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f1e018080 +SigHash 0x50eef45abe0743dce17e40db185d1d85607245a545f7517a52b90f3673aff689 +Signature f845f84326a0769f0afdc310289f9b24decb5bb765c8d7a87a6a4ae28edffb8b7085bbd9bc78a06a7b970eea026e60ac29bb52aee10661a4222e6bdcdfb3839a80586e584586b4 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf857b83df83b128204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f1e945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0x09583a871c38a4860e336bfa5f16003feec75e710cfd9186c37892cee7d9775b +SignatureFeePayer f845f84325a0c1c54bdc72ce7c08821329bf50542535fac74f4bba5de5b7881118a461d52834a03a3a64878d784f9af91c2e3ab9c90f17144c47cfd9951e3588c75063c0649ecd +TxHashRLP 0x12f8dd8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f1ef845f84326a0769f0afdc310289f9b24decb5bb765c8d7a87a6a4ae28edffb8b7085bbd9bc78a06a7b970eea026e60ac29bb52aee10661a4222e6bdcdfb3839a80586e584586b4945a0043070275d9f6054307ee7348bd660849d90ff845f84325a0c1c54bdc72ce7c08821329bf50542535fac74f4bba5de5b7881118a461d52834a03a3a64878d784f9af91c2e3ab9c90f17144c47cfd9951e3588c75063c0649ecd +TxHash abcb0fd8ebb8f62ac899e5211b9ba47fe948a8efd815229cc4ed9cd781464f15 +SenderTxHashRLP 0x12f87b8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84326a0769f0afdc310289f9b24decb5bb765c8d7a87a6a4ae28edffb8b7085bbd9bc78a06a7b970eea026e60ac29bb52aee10661a4222e6bdcdfb3839a80586e584586b4 +SenderTxHash 2c4e8cd3c68a4aacae51c695e857cfc1a019037ca71d8cd1e8ca56ec4eaf55b1 + + TX(abcb0fd8ebb8f62ac899e5211b9ba47fe948a8efd815229cc4ed9cd781464f15) + Type: TxTypeFeeDelegatedValueTransferMemoWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Signature: [{"V":"0x26","R":"0x769f0afdc310289f9b24decb5bb765c8d7a87a6a4ae28edffb8b7085bbd9bc78","S":"0x6a7b970eea026e60ac29bb52aee10661a4222e6bdcdfb3839a80586e584586b4"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeeRatio: 30 + FeePayerSig: [{"V":"0x25","R":"0xc1c54bdc72ce7c08821329bf50542535fac74f4bba5de5b7881118a461d52834","S":"0x3a3a64878d784f9af91c2e3ab9c90f17144c47cfd9951e3588c75063c0649ecd"}] + Data: 36383635366336633666 + Hex: 12f8dd8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0b8568656c6c6f1ef845f84326a0769f0afdc310289f9b24decb5bb765c8d7a87a6a4ae28edffb8b7085bbd9bc78a06a7b970eea026e60ac29bb52aee10661a4222e6bdcdfb3839a80586e584586b4945a0043070275d9f6054307ee7348bd660849d90ff845f84325a0c1c54bdc72ce7c08821329bf50542535fac74f4bba5de5b7881118a461d52834a03a3a64878d784f9af91c2e3ab9c90f17144c47cfd9951e3588c75063c0649ecd +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x7ad6ed1f9955be00db8fb5452125f0e9a3c0856abb5b4cc4aed91ffc134321da", + "blockNumber": "0x1", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x26", + "R": "0x1f71cc0dee26dce62a987d189650ee62a6751fcde1c7f7915abaf6c0137930da", + "S": "0x585115c7eecb3a88e3805a90be8cb6458f245029274a781afd2b867579ff73fa" + } + ], + "feeRatio": "0x1e", + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0x8e94", + "input": "0x68656c6c6f", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x6", + "senderTxHash": "0xe68e9194c5448d17137f00aae392ade4d8a143c1ae4f3c5a2340a332bce009e4", + "signatures": [ + { + "V": "0x25", + "R": "0x60e5da74cc0f7d73b57dc4b2a5bb7dd05d40757b47febc079e3a43769878abc3", + "S": "0x68e16f2a7bce21e16cebbe22a3624aa5edd814dd74a70ab8aaf850cd7a4b757f" + } + ], + "status": "0x1", + "to": "0x75c3098be5e4b63fbac05838daaee378dd48098d", + "transactionHash": "0xda18ebcf420af8a0a7acf6636711540f71b8bb65bc86e960e6a6bbb665a062f3", + "transactionIndex": "0x6", + "type": "TxTypeFeeDelegatedValueTransferMemoWithRatio", + "typeInt": 18, + "value": "0x989680" +} +``` + +## TxTypeFeeDelegatedSmartContractDeployWithRatio + +TxTypeFeeDelegatedSmartContractDeployWithRatio はスマートコントラクトをデプロイします。 取引手数料の所定の比率は、手数料支払者が支払う。 このトランザクションタイプでは、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料額の手数料率分だけ減少する。 +2. 送信者の残高は、残りの取引手数料分だけ減少する。 例えば、`feeRatio`が30であれば、手数料の30%は手数料を支払う側が支払い、残りの70%は手数料を支払う側が支払うことになります。 +3. 送信者のnonceは1増加する。 +4. スマートコントラクトは `input` のコードとともにデプロイされる。 配置されたアドレスは、レシートの `contractAddress` を介して返される。 +5. `value` KAIAは送信者から受信者に転送される。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedSmartContractDeployWithRatio の型。 これは0x2aでなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送信者が取引手数料として支払うガスの単価。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できるガスの最大量。 | +| to | \*common.Address \(Go\) | 送金された金額を受け取る口座アドレス。 現在、この値はnilでなければならない。 アドレスの指定は将来サポートされる予定。 | +| value | \*big.Int \(Go\) | 送金されるKAIAの金額(`kei`)。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| humanReadable | bool \(Go\) | 人間が読めるアドレスはまだサポートされていないので、これは偽でなければならない。 trueの場合、トランザクションは拒否される。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| codeFormat | uint8 \(Go\) | スマート・コントラクトのコード形式。 The supported value for now is EVM(0x00) only. | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, humanReadable, feeRatio, codeFormat]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, humanReadable, feeRatio, codeFormat]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, humanReadable, feeRatio, codeFormat, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, humanReadable, feeRatio, codeFormat, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf90241b9023bf902382a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029011e80018080 +SigHash 0x000db9e2246975d7242e2fb45279ff42bc0269e544e3b1589ea78e760775cc2c +Signature f845f84326a0cfe8dc29d31916b3f661a4774cb8d44d39ae700a9fb6ca04327f84bbe4de1486a01616e09ced403420cac1363d14e705b7a323518b1ce5124b16f06871c00ac424 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf90256b9023bf902382a8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029011e80945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0xedd4031ccfb27867cbd856192cec0a538ab25f6bc632f3075bf7be8368983cea +SignatureFeePayer f845f84325a0e29dae81defc027f059cd6a55ff74156b9c5bdb811460f09fc8d167c01aaaea1a04eba34d4d5ebbce60e4998f03b7a4658263bb21063ddf68ad3b088d670de47c8 +TxHashRLP 0x2af902da8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029011e80f845f84326a0cfe8dc29d31916b3f661a4774cb8d44d39ae700a9fb6ca04327f84bbe4de1486a01616e09ced403420cac1363d14e705b7a323518b1ce5124b16f06871c00ac424945a0043070275d9f6054307ee7348bd660849d90ff845f84325a0e29dae81defc027f059cd6a55ff74156b9c5bdb811460f09fc8d167c01aaaea1a04eba34d4d5ebbce60e4998f03b7a4658263bb21063ddf68ad3b088d670de47c8 +TxHash 54b6f267c2dd508ffdd9d41fd6d04847ad975cede8fcd4d5af58ca959c534946 +SenderTxHashRLP 0x2af9027e8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029011e80f845f84326a0cfe8dc29d31916b3f661a4774cb8d44d39ae700a9fb6ca04327f84bbe4de1486a01616e09ced403420cac1363d14e705b7a323518b1ce5124b16f06871c00ac424 +SenderTxHash 57dfef9c923cba182cca00fa65d45aaf619613d843d585d3c4026a3bd0797366 + + TX(54b6f267c2dd508ffdd9d41fd6d04847ad975cede8fcd4d5af58ca959c534946) + Type: TxTypeFeeDelegatedSmartContractDeployWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Data: 363038303630343035323334383031353631303031303537363030303830666435623530363130316465383036313030323036303030333936303030663330303630383036303430353236303034333631303631303036313537363366666666666666663763303130303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303630303033353034313636333161333964386566383131343631303038303537383036333633353335383662313436313030613735373830363337306130383233313134363130306361353738303633666436623765663831343631303066383537356233333630303039303831353236303031363032303532363034303831323038303534333439303831303139303931353538313534303139303535303035623334383031353631303038633537363030303830666435623530363130303935363130313064353635623630343038303531393138323532353139303831393030333630323030313930663335623631303063383733666666666666666666666666666666666666666666666666666666666666666666666666666666663630303433353136363130313133353635623030356233343830313536313030643635373630303038306664356235303631303039353733666666666666666666666666666666666666666666666666666666666666666666666666666666663630303433353136363130313437353635623334383031353631303130343537363030303830666435623530363130306338363130313539353635623630303035343831353635623733666666666666666666666666666666666666666666666666666666666666666666666666666666663136363030303930383135323630303136303230353236303430383132303830353433343930383130313930393135353831353430313930353535363562363030313630323035323630303039303831353236303430393032303534383135363562333336303030393038313532363030313630323035323630343038313230383035343930383239303535393038313131313536313031616635373630343035313333393038323135363130386663303239303833393036303030383138313831383538383838663139333530353035303530313536313031396335373631303161663536356233333630303039303831353236303031363032303532363034303930323038313930353535623530353630306131363536323761376137323330353832303632376361343662623039343738613031353736323830366363303063343331323330353031313138633763323663333061633538633465303965353163346630303239 + HumanReadable: true + Signature: [{"V":"0x26","R":"0xcfe8dc29d31916b3f661a4774cb8d44d39ae700a9fb6ca04327f84bbe4de1486","S":"0x1616e09ced403420cac1363d14e705b7a323518b1ce5124b16f06871c00ac424"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeeRatio: 30 + CodeFormat: CodeFormatEVM + FeePayerSig: [{"V":"0x25","R":"0xe29dae81defc027f059cd6a55ff74156b9c5bdb811460f09fc8d167c01aaaea1","S":"0x4eba34d4d5ebbce60e4998f03b7a4658263bb21063ddf68ad3b088d670de47c8"}] + Hex: 2af902da8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0bb901fe608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029011e80f845f84326a0cfe8dc29d31916b3f661a4774cb8d44d39ae700a9fb6ca04327f84bbe4de1486a01616e09ced403420cac1363d14e705b7a323518b1ce5124b16f06871c00ac424945a0043070275d9f6054307ee7348bd660849d90ff845f84325a0e29dae81defc027f059cd6a55ff74156b9c5bdb811460f09fc8d167c01aaaea1a04eba34d4d5ebbce60e4998f03b7a4658263bb21063ddf68ad3b088d670de47c8 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "codeFormat": "0x0", + "contractAddress": "0x636f6e7472616374332e6b6c6179746e00000000", + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x9dbd19852ce8d1bc36389c73aa45733ccd2af0186d78952ca2b7bf3828227c02", + "S": "0x184f60af32203d5abd0e1ac8820887cc96189d4efc1ccddb5fb966e29a07c9cf" + } + ], + "feeRatio": "0x21", + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x0", + "gasUsed": "0xee6e6ed5", + "humanReadable": true, + "input": "0x608060405234801561001057600080fd5b506101de806100206000396000f3006080604052600436106100615763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631a39d8ef81146100805780636353586b146100a757806370a08231146100ca578063fd6b7ef8146100f8575b3360009081526001602052604081208054349081019091558154019055005b34801561008c57600080fd5b5061009561010d565b60408051918252519081900360200190f35b6100c873ffffffffffffffffffffffffffffffffffffffff60043516610113565b005b3480156100d657600080fd5b5061009573ffffffffffffffffffffffffffffffffffffffff60043516610147565b34801561010457600080fd5b506100c8610159565b60005481565b73ffffffffffffffffffffffffffffffffffffffff1660009081526001602052604081208054349081019091558154019055565b60016020526000908152604090205481565b336000908152600160205260408120805490829055908111156101af57604051339082156108fc029083906000818181858888f193505050501561019c576101af565b3360009081526001602052604090208190555b505600a165627a7a72305820627ca46bb09478a015762806cc00c431230501118c7c26c30ac58c4e09e51c4f0029", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0xc", + "senderTxHash": "0xe24e58467268601dc5131fb9719ebbb4bed16244af05c37d916a92c98a6a62a5", + "signatures": [ + { + "V": "0x26", + "R": "0xb9497df1dd5c37786570f26745112fb828fb7b6de851bc11562eab77a76462b1", + "S": "0x6231f2945f01004e68388ad1103cb00fd4f3f8b782667030d99779ecd47d7462" + } + ], + "status": "0x1", + "to": "0x636f6e7472616374332e6b6c6179746e00000000", + "transactionHash": "0x32944e85f2255b7ebc1101b136938a758295d57dca1203b997e7ee7873dd9eec", + "transactionIndex": "0x5", + "type": "TxTypeFeeDelegatedSmartContractDeployWithRatio", + "typeInt": 42, + "value": "0x0" +} +``` + +## TxTypeFeeDelegatedSmartContractExecutionWithRatio + +TxTypeFeeDelegatedSmartContractExecution は `input` に指定されたデータでスマートコントラクトを実行する。 TxTypeFeeDelegatedSmartContractExecutionWithRatio は、`to` がスマートコントラクトアカウントである場合にのみ受理される。 To transfer KLAY to an externally owned account, use [TxTypeFeeDelegatedValueTransferWithRatio](#txtypefeedelegatedvaluetransferwithratio) instead. このトランザクションタイプでは、以下の変更が行われる。 + +1. もし `to` がスマートコントラクトのアカウントであれば、`input` に基づいてコードが実行される。 そうでない場合、このトランザクションは拒否される。 +2. 手数料支払者の残高は、取引手数料額の手数料率分だけ減少する。 +3. 送信者の残高は、残りの取引手数料分だけ減少する。 例えば、`feeRatio`が30であれば、手数料の30%は手数料を支払う側が支払い、残りの70%は手数料を支払う側が支払うことになります。 +4. 送信者のnonceは1増加する。 +5. `value` が提供された場合、`value` KAIA は送信者から `to` スマートコントラクトに転送される。 The contract should have a payable fallback function to receive KLAY. + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedSmartContractExecutionWithRatio の型。 これは0x32でなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できるガスの最大量。 | +| to | common.Address \(Go\) | 実行されるスマートコントラクトアカウントのアドレス。 | +| value | \*big.Int \(Go\) | 譲渡される`kei`のKAIAの量。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| input | \[\]byte \(Go\) | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, feeRatio]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, to, value, from, input, feeRatio]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, feeRatio, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +TxHashRLP = type + encode([nonce, gasPrice, gas, to, value, from, input, feeRatio, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf861b85cf85a328204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b21e018080 +SigHash 0x1eeea77acecdd102a070ead80a00f388e039c11d813e6d4a63ec90bd0186b210 +Signature f845f84326a074ccfee18dc28932396b85617c53784ee366303bce39a2401d8eb602cf73766fa04c937a5ab9401d2cacb3f39ba8c29dbcd44588cc5c7d0b6b4113cfa7b7d9427b +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf876b85cf85a328204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b21e945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0x8a13f42530219cddb490108e38c48e7b58bc02a82f4d797d8f4d85eb16f6d6a5 +SignatureFeePayer f845f84325a04a4997524694d535976d7343c1e3a260f99ba53fcb5477e2b96216ec96ebb565a00f8cb31a35399d2b0fbbfa39f259c819a15370706c0449952c7cfc682d200d7c +TxHashRLP 0x32f8fc8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b21ef845f84326a074ccfee18dc28932396b85617c53784ee366303bce39a2401d8eb602cf73766fa04c937a5ab9401d2cacb3f39ba8c29dbcd44588cc5c7d0b6b4113cfa7b7d9427b945a0043070275d9f6054307ee7348bd660849d90ff845f84325a04a4997524694d535976d7343c1e3a260f99ba53fcb5477e2b96216ec96ebb565a00f8cb31a35399d2b0fbbfa39f259c819a15370706c0449952c7cfc682d200d7c +TxHash b204e530f2a7f010d65b6f0f7639d1e9fc8add73e3a0ff1551b11585c36d3bdb +SenderTxHashRLP 0x32f8a08204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b21ef845f84326a074ccfee18dc28932396b85617c53784ee366303bce39a2401d8eb602cf73766fa04c937a5ab9401d2cacb3f39ba8c29dbcd44588cc5c7d0b6b4113cfa7b7d9427b +SenderTxHash d5e22319cbf020d422d8ba3a07da9d99b9300826637af85b4e061805dcb2c1b0 + + TX(b204e530f2a7f010d65b6f0f7639d1e9fc8add73e3a0ff1551b11585c36d3bdb) + Type: TxTypeFeeDelegatedSmartContractExecutionWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + To: 0x7b65B75d204aBed71587c9E519a89277766EE1d0 + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Value: 0xa + Data: 363335333538366230303030303030303030303030303030303030303030303062633539353166303535613835663431613362363266643666363861623764653736643239396232 + Signature: [{"V":"0x26","R":"0x74ccfee18dc28932396b85617c53784ee366303bce39a2401d8eb602cf73766f","S":"0x4c937a5ab9401d2cacb3f39ba8c29dbcd44588cc5c7d0b6b4113cfa7b7d9427b"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeeRatio: 30 + FeePayerSig: [{"V":"0x25","R":"0x4a4997524694d535976d7343c1e3a260f99ba53fcb5477e2b96216ec96ebb565","S":"0xf8cb31a35399d2b0fbbfa39f259c819a15370706c0449952c7cfc682d200d7c"}] + Hex: 32f8fc8204d219830f4240947b65b75d204abed71587c9e519a89277766ee1d00a94a94f5374fce5edbc8e2a8697c15331677e6ebf0ba46353586b000000000000000000000000bc5951f055a85f41a3b62fd6f68ab7de76d299b21ef845f84326a074ccfee18dc28932396b85617c53784ee366303bce39a2401d8eb602cf73766fa04c937a5ab9401d2cacb3f39ba8c29dbcd44588cc5c7d0b6b4113cfa7b7d9427b945a0043070275d9f6054307ee7348bd660849d90ff845f84325a04a4997524694d535976d7343c1e3a260f99ba53fcb5477e2b96216ec96ebb565a00f8cb31a35399d2b0fbbfa39f259c819a15370706c0449952c7cfc682d200d7c +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x26", + "R": "0xfd7cbb13af34814ae5072b7078e9d98ca1806859f452c7369c88fed70150ddee", + "S": "0x6edee3341b62a2ef1488636a9395bc236ebcdfebc76ee3c933d48a65ea89440e" + } + ], + "feeRatio": "0x42", + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x0", + "gasUsed": "0xc444", + "input": "0x6353586b0000000000000000000000000fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0xf", + "senderTxHash": "0x5545f40855ac02770f8738629d2e81bd3d04df3d90bb2b6e676a10e747c0d946", + "signatures": [ + { + "V": "0x26", + "R": "0xaf1fdf0874424ed6d86b1408d24e2dff36046669cf9d99282bec4a50713adfa6", + "S": "0x20f25bf30b0d906cee734396914a5497076a7f50ce83954b09c9f46415af8f1" + } + ], + "status": "0x1", + "to": "0x636f6e74726163742e6b6c6179746e0000000000", + "transactionHash": "0xc4af8d6b3353ad3ad240a747d185a094c6e751373c3c08c669eb37c50f01b7b1", + "transactionIndex": "0x8", + "type": "TxTypeFeeDelegatedSmartContractExecutionWithRatio", + "typeInt": 50, + "value": "0xa" +} +``` + +## TxTypeFeeDelegatedAccountUpdateWithRatio + +TxTypeFeeDelegatedAccountUpdateWithRatio は、指定された口座のキーを更新します。 取引手数料の所定の比率は、手数料支払者が支払う。 このトランザクションタイプによって、以下の変更が行われる。 + +1. 手数料支払者の残高は、取引手数料額の手数料率分だけ減少する。 +2. 送信者の残高は、残りの取引手数料分だけ減少する。 例えば、`feeRatio`が30であれば、手数料の30%は手数料を支払う側が支払い、残りの70%は手数料を支払う側が支払うことになります。 +3. 送信者のnonceは1増加する。 +4. アカウントのキーは `key` で更新される。 +5. このトランザクションが実行されると、その後アカウントから送信されたトランザクションはこの `key` で検証されます。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedAccountUpdateWithRatio の型。 これは0x22でなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの金額は `gas` ⑭ `gasPrice` によって計算される。 For example, the sender will pay 10 KLAY for a transaction fee if gas is 10 and gasPrice is 10^18. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| key | AccountKey \(Go\) | [AccountKey](../accounts.md#account-key)をアカウントに更新する。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, rlpEncodedKey, feeRatio]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, from, rlpEncodedKey, feeRatio]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, rlpEncodedKey, feeRatio, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, rlpEncodedKey, feeRatio, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf84ab845f843228204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d1e018080 +SigHash 0x706ba7cd01e44008077a2abeafc3aacd64cbf210f49c64983f295a2e4cc03216 +Signature f845f84326a00e5929f96dec2b41343a9e6f0150eef08741fe7dcece88cc5936c49ed19051dca05a07b07017190e0baba32bdf6352f5a358a2798ed3c56e704a63819b87cf8e3f +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf85fb845f843228204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d1e945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0xd2a51cefec667747890e6bd11fd068e8796b5446f77e152367eaa3cf98c96b30 +SignatureFeePayer f845f84326a0cf8d102de7c6b0a41d3f02aefb7e419522341734c98af233408298d0c424c04ba00286f89cab4668f728d7c269997116a49b80cec8776fc64e60588a9268571e35 +TxHashRLP 0x22f8e58204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d1ef845f84326a00e5929f96dec2b41343a9e6f0150eef08741fe7dcece88cc5936c49ed19051dca05a07b07017190e0baba32bdf6352f5a358a2798ed3c56e704a63819b87cf8e3f945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0cf8d102de7c6b0a41d3f02aefb7e419522341734c98af233408298d0c424c04ba00286f89cab4668f728d7c269997116a49b80cec8776fc64e60588a9268571e35 +TxHash 276f02c25ca4ced081dcfbb836755ced574993b047e648a583ed8d4144b3813f +SenderTxHashRLP 0x22f8898204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d1ef845f84326a00e5929f96dec2b41343a9e6f0150eef08741fe7dcece88cc5936c49ed19051dca05a07b07017190e0baba32bdf6352f5a358a2798ed3c56e704a63819b87cf8e3f +SenderTxHash e1d87538509549f4a1eb418f986bc53dc77b7eec3b2150f75cd787951d3e4b7f + + TX(276f02c25ca4ced081dcfbb836755ced574993b047e648a583ed8d4144b3813f) + Type: TxTypeFeeDelegatedAccountUpdateWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Key: AccountKeyPublic: S256Pubkey:{"x":"0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d","y":"0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3"} + Signature: [{"V":"0x26","R":"0xe5929f96dec2b41343a9e6f0150eef08741fe7dcece88cc5936c49ed19051dc","S":"0x5a07b07017190e0baba32bdf6352f5a358a2798ed3c56e704a63819b87cf8e3f"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeeRatio: 30 + FeePayerSig: [{"V":"0x26","R":"0xcf8d102de7c6b0a41d3f02aefb7e419522341734c98af233408298d0c424c04b","S":"0x286f89cab4668f728d7c269997116a49b80cec8776fc64e60588a9268571e35"}] + Hex: 22f8e58204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0ba302a1033a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d1ef845f84326a00e5929f96dec2b41343a9e6f0150eef08741fe7dcece88cc5936c49ed19051dca05a07b07017190e0baba32bdf6352f5a358a2798ed3c56e704a63819b87cf8e3f945a0043070275d9f6054307ee7348bd660849d90ff845f84326a0cf8d102de7c6b0a41d3f02aefb7e419522341734c98af233408298d0c424c04ba00286f89cab4668f728d7c269997116a49b80cec8776fc64e60588a9268571e35 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0xfa3690925bae82ba662abe6d3af8993b7a7994d9f922cb1ae83c59c4a26a3b70", + "S": "0x2bd481ddf40cb813dde5f67db0e3a6ad9ea46758ef97580a709b301c21530246" + } + ], + "feeRatio": "0xb", + "from": "0x636f6c696e332e6b6c6179746e00000000000000", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0xdac0", + "key": "0x02a102c8785266510368d9372badd4c7f4a94b692e82ba74e0b5e26b34558b0f081447", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x0", + "senderTxHash": "0x74be8f01f10a497dbe9ed10659ac8c4579b37f8b5022b9f7eec6362262d44845", + "signatures": [ + { + "V": "0x25", + "R": "0xd17d2ae2290b35c560289797c955fa5dc1cc25606cfd198584665917da6795ff", + "S": "0x7bc0450ff7319ccdbf50d38095501b895717cac775c6897d2381e7182aa25742" + } + ], + "status": "0x1", + "transactionHash": "0x90ccbf85ffd1f7e74620840fd9d270e030c6719e3c7b70bb8796c1cedf02fe88", + "transactionIndex": "0x1", + "type": "TxTypeFeeDelegatedAccountUpdateWithRatio", + "typeInt": 34 +} +``` + +## TxTypeFeeDelegatedCancelWithRatio + +TxTypeFeeDelegatedCancelWithRatio は、トランザクションプール中の同じnonceを持つトランザク ションの実行をキャンセルする。 詳細については、[TxTypeCancel](./basic.md#txtypecancel) を参照のこと。 + +このトランザクションタイプでは、以下の変更が適用される。 1. 手数料支払者の残高は、取引手数料額の所定の手数料率分だけ減少する。 2. 送信者の残高は、残りの取引手数料分だけ減少する。 3. 送信者のnonceは1増加する。 + +### 属性 + +| 属性 | 説明 | タイプ | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedCancelWithRatio の型。 これは0x3aでなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, feeRatio]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, from, feeRatio]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, feeRatio, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPricke, gas, from, feeRatio, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x1 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xe4a0df3a8204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b1e018080 +SigHash 0xeccd1585e8e105bc034a72190c3e9312b5407736686aa0d34b1ad75320871014 +Signature f845f84326a072efa47960bef40b536c72d7e03ceaf6ca5f6061eb8a3eda3545b1a78fe52ef5a062006ddaf874da205f08b3789e2d014ae37794890fc2e575bf75201563a24ba9 +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf839a0df3a8204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b1e945a0043070275d9f6054307ee7348bd660849d90f018080 +SigHashFeePayer 0xf71b0b22d72ef59a063a865ee844e1ba0a103d707f06fb7013b3372ed169c705 +SignatureFeePayer f845f84326a06ba5ef20c3049323fc94defe14ca162e28b86aa64f7cf497ac8a5520e9615614a04a0a0fc61c10b416759af0ce4ce5c09ca1060141d56d958af77050c9564df6bf +TxHashRLP 0x3af8c18204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84326a072efa47960bef40b536c72d7e03ceaf6ca5f6061eb8a3eda3545b1a78fe52ef5a062006ddaf874da205f08b3789e2d014ae37794890fc2e575bf75201563a24ba9945a0043070275d9f6054307ee7348bd660849d90ff845f84326a06ba5ef20c3049323fc94defe14ca162e28b86aa64f7cf497ac8a5520e9615614a04a0a0fc61c10b416759af0ce4ce5c09ca1060141d56d958af77050c9564df6bf +TxHash 63604ebf68bfee51b2e3f54ddb2f19f9ea72d32b3fc70877324531ecda25817a +SenderTxHashRLP 0x3af8658204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84326a072efa47960bef40b536c72d7e03ceaf6ca5f6061eb8a3eda3545b1a78fe52ef5a062006ddaf874da205f08b3789e2d014ae37794890fc2e575bf75201563a24ba9 +SenderTxHash c0818be4cffbacfe29be1134e0267e10fd1afb6571f4ccc95dcc67a788bab5e7 + + TX(63604ebf68bfee51b2e3f54ddb2f19f9ea72d32b3fc70877324531ecda25817a) + Type: TxTypeFeeDelegatedCancelWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 1234 + GasPrice: 0x19 + GasLimit: 0xf4240 + Signature: [{"V":"0x26","R":"0x72efa47960bef40b536c72d7e03ceaf6ca5f6061eb8a3eda3545b1a78fe52ef5","S":"0x62006ddaf874da205f08b3789e2d014ae37794890fc2e575bf75201563a24ba9"}] + FeePayer: 0x5A0043070275d9f6054307Ee7348bD660849D90f + FeeRatio: 30 + FeePayerSig: [{"V":"0x26","R":"0x6ba5ef20c3049323fc94defe14ca162e28b86aa64f7cf497ac8a5520e9615614","S":"0x4a0a0fc61c10b416759af0ce4ce5c09ca1060141d56d958af77050c9564df6bf"}] + Hex: 3af8c18204d219830f424094a94f5374fce5edbc8e2a8697c15331677e6ebf0b1ef845f84326a072efa47960bef40b536c72d7e03ceaf6ca5f6061eb8a3eda3545b1a78fe52ef5a062006ddaf874da205f08b3789e2d014ae37794890fc2e575bf75201563a24ba9945a0043070275d9f6054307ee7348bd660849d90ff845f84326a06ba5ef20c3049323fc94defe14ca162e28b86aa64f7cf497ac8a5520e9615614a04a0a0fc61c10b416759af0ce4ce5c09ca1060141d56d958af77050c9564df6bf +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0x82983fe294d286e76486760e6904369285554e1744af16786c2393a956fb4ec4", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x029fdce0457db02f05c4be9f67b7115cb8ea15ca", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0x26c8b5038e9f7ff580f3323b8a06b6eb1b6ab13cac11c30de6c9b64230bdb992", + "S": "0x6c4be67ace8551237e675da2b7b32ec2d7d7e07abf2eb299ebec6cc444460e13" + } + ], + "feeRatio": "0x58", + "from": "0x0fcda0f2efbe1b4e61b487701ce4f2f8abc3723d", + "gas": "0x174876e800", + "gasPrice": "0x0", + "gasUsed": "0x8ca0", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x12", + "senderTxHash": "0xc9d2f558f6883bfea5113ce900499354fcb0004ff901dec51db7a5d80c3a7868", + "signatures": [ + { + "V": "0x26", + "R": "0x88a484d1cc59824e05b933348df6ebe7b82ac68766a85e2aa5636c136ee2834c", + "S": "0x104fee953e1a015f26b35da57acf15aa01eb5c6c0e79965200c3fe813003a4fe" + } + ], + "status": "0x1", + "transactionHash": "0x50c6840fee3297a8ff745025cb4fd27a7e662395620ad615458ea22034f37f6c", + "transactionIndex": "0xb", + "type": "TxTypeFeeDelegatedCancelWithRatio", + "typeInt": 58 +} +``` + +## TxTypeFeeDelegatedChainDataAnchoringWithRatio + +TxTypeFeeDelegatedChainDataAnchoringWithRatioは、サービスチェーンデータをカイアメインチェーンにアンカーする、比率を持つ手数料委任トランザクションである。 +サービスチェーンはこの種のトランザクションを定期的にKaiaメインチェーンに送信し、データの安全性と信頼性を確保します。 +データ・アンカリングの詳細については、[アンカリング](../../nodes/service-chain/configure/anchoring.md)を参照のこと。 +この取引も所定の比率による手数料委任取引であるため、手数料支払者は所定の比率に基づく取引手数料の所定の部分のみを負担し、残りを送金者が支払う。 +このトランザクションをRPC経由で送信することは禁じられている。 +現在、この取引はセキュリティ上の理由から、プライベートなp2pチャネルを通じて実行されている。 +このトランザクションは、送信者のnonceが1増加した以外は、Kaiaブロックチェーンの状態を変更しない。 + +### 属性 + +| 属性 | タイプ | 説明 | +| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| type | uint8 \(Go\) | TxTypeFeeDelegatedChainDataAnchoringWithRatio の型。 これは0x4aでなければならない。 | +| nonce | uint64 \(Go\) | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| gasPrice | \*big.Int \(Go\) | 送金者は、`kei`単位のガス料金を取引手数料として支払う。 取引手数料の金額は、`gas` \* `gasPrice` として計算されます。 For example, if the transaction consumes 10 units of gas and gasPrice is 10^18, the transaction fee will be 10 KLAY. KAIAのユニット](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照。 | +| gas | uint64 \(Go\) | トランザクションが使用できる取引手数料の上限額。 | +| from | common.Address \(Go\) | 送信者のアドレス。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feeRatio | uint8 \(Go\) | 料金支払者の料金比率。 有効範囲は1～99。 Zero(0) is not allowed. 100点以上も不可。 | +| input | \[\]byte \(Go\) | サービスチェーンのデータ。 | +| txSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 送信者の署名。 詳細は[署名検証](./transactions.md#signature-validation)を参照。 | +| feePayer | common.Address \(Go\) | 料金支払者の住所。 | +| feePayerSignatures | \[\]\{\*big.Int, \*big.Int, \*big.Int\} \(Go\) | 料金支払者の署名 | + +### 送信者の署名のためのRLPエンコーディング + +送信者の署名を作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigRLP = encode([encode([type, nonce, gasPrice, gas, from, anchoredData, feeRatio]), chainid, 0, 0]) +SigHash = keccak256(SigRLP) +Signature = sign(SigHash, ) +``` + +### 料金支払者の署名のためのRLPエンコーディング + +料金支払者の署名を作成するには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +SigFeePayerRLP = encode([encode([type, nonce, gasPrice, gas, from, anchoredData, feeRatio]), feePayer, chainid, 0, 0]) +SigFeePayerHash = keccak256(SigFeePayerRLP) +SignatureFeePayer = sign(SigFeePayerHash, ) +``` + +### SenderTxHashのRLPエンコーディング + +SenderTxHashを作るには、以下のようにRLPシリアライズを行う必要があります： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +SenderTxHashRLP = type + encode([nonce, gasPrice, gas, from, anchoredData, feeRatio, txSignatures]) +SenderTxHash = keccak256(SenderTxHashRLP) +``` + +### トランザクション・ハッシュのRLPエンコーディング + +トランザクション・ハッシュを作るには、以下のようにRLPシリアライズを行う必要がある： + +```javascript +txSignatures (a single signature) = [[v, r, s]] +txSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +feePayerSignatures (a single signature) = [[v, r, s]] +feePayerSignatures (two signatures) = [[v1, r1, s1], [v2, r2, s2]] +TxHashRLP = type + encode([nonce, gasPrice, gas, from, anchoredData, feeRatio, txSignatures, feePayer, feePayerSignatures]) +TxHash = keccak256(TxHashRLP) +``` + +### RLP Encoding (Example) + +以下は、RLPシリアライズの結果とトランザクション・オブジェクトを示している： + +```javascript +ChainID 0x01 +PrivateKey 0x45a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d8 +PublicKey.X 0x3a514176466fa815ed481ffad09110a2d344f6c9b78c1d14afc351c3a51be33d +PublicKey.Y 0x8072e77939dc03ba44790779b7a1025baf3003f6732430e20cd9b76d953391b3 +SigRLP 0xf8dcb8d7f8d54a128505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405800658018080 +SigHash 0xd79dbb964bee2d3807e214a247141a1fcb066a67de99e90750aac4a2a0b776de +Signature 0xf845f84326a0c612a243bcb3b98958e9cce1a0bc0e170291b33a7f0dbfae4b36dafb5806797da00c734423492ecc21cc53238147c359676fcec43fcc2a0e021d87bb1da49f0abf +FeePayerPrivateKey 0xb9d5558443585bca6f225b935950e3f6e69f9da8a5809a83f51c3365dff53936 +FeePayerPublicKey.X 0x327434d4cfc66ef8857d431419e9deebdc53a3e415edcc55382e2d417b8dd102 +FeePayerPublicKey.Y 0x65fc97045707faf7b8f81ac65089d4cc71f69ad0bf1bc8559bc24f13fc284ced +SigRLPFeePayer 0xf8f1b8d7f8d54a128505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006589433f524631e573329a550296f595c820d6c65213f018080 +SigHashFeePayer 0xa824ff743912239d0665d2fd43a66d57138c92834e9d338b66bcca4a0bee8fbd +SignatureFeePayer 0xf845f84325a0a3e40598b67e2bcbaa48fdd258b9d1dcfcc9cc134972560ba042430078a769a5a06707ea362e588e4e5869cffcd5a058749d823aeff13eb95dc1146faff561df32 +TxHashRLP 0x4af90177128505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405800658f845f84326a0c612a243bcb3b98958e9cce1a0bc0e170291b33a7f0dbfae4b36dafb5806797da00c734423492ecc21cc53238147c359676fcec43fcc2a0e021d87bb1da49f0abf9433f524631e573329a550296f595c820d6c65213ff845f84325a0a3e40598b67e2bcbaa48fdd258b9d1dcfcc9cc134972560ba042430078a769a5a06707ea362e588e4e5869cffcd5a058749d823aeff13eb95dc1146faff561df32 +TxHash 0xc01a7c3ece18c115b58d7747669ec7c31ec5ab031a88cb49ad85a31f6dbbf915 +SenderTxHashRLP 0x4af9011b128505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405800658f845f84326a0c612a243bcb3b98958e9cce1a0bc0e170291b33a7f0dbfae4b36dafb5806797da00c734423492ecc21cc53238147c359676fcec43fcc2a0e021d87bb1da49f0abf +SenderTxHash 0xa0670c01fe39feb2d2442adf7df1957ade3c5abcde778fb5edf99c80c06aa53c + + TX(c01a7c3ece18c115b58d7747669ec7c31ec5ab031a88cb49ad85a31f6dbbf915) + Type: TxTypeFeeDelegatedChainDataAnchoringWithRatio + From: 0xa94f5374Fce5edBC8E2a8697C15331677e6EbF0B + Nonce: 18 + GasPrice: 0x5d21dba00 + GasLimit: 0x174876e800 + AnchoredData: f8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006 + Signature: [{"V":"0x26","R":"0xc612a243bcb3b98958e9cce1a0bc0e170291b33a7f0dbfae4b36dafb5806797d","S":"0xc734423492ecc21cc53238147c359676fcec43fcc2a0e021d87bb1da49f0abf"}] + FeePayer: 0x33f524631e573329a550296F595c820D6c65213f + FeeRatio: 88 + FeePayerSig: [{"V":"0x25","R":"0xa3e40598b67e2bcbaa48fdd258b9d1dcfcc9cc134972560ba042430078a769a5","S":"0x6707ea362e588e4e5869cffcd5a058749d823aeff13eb95dc1146faff561df32"}] + Hex: 4af90177128505d21dba0085174876e80094a94f5374fce5edbc8e2a8697c15331677e6ebf0bb8aff8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a0000000000000000000000000000000000000000000000000000000000000000405800658f845f84326a0c612a243bcb3b98958e9cce1a0bc0e170291b33a7f0dbfae4b36dafb5806797da00c734423492ecc21cc53238147c359676fcec43fcc2a0e021d87bb1da49f0abf9433f524631e573329a550296f595c820d6c65213ff845f84325a0a3e40598b67e2bcbaa48fdd258b9d1dcfcc9cc134972560ba042430078a769a5a06707ea362e588e4e5869cffcd5a058749d823aeff13eb95dc1146faff561df32 +``` + +### RPC Output (Example) + +以下は、JSON RPCを介して返されるトランザクション・オブジェクトを示している。 + +```javascript +{ + "blockHash": "0xee6c72b7d99019a941b47d77507abe015c3f00d3ff9122a2eec33d846107b842", + "blockNumber": "0x2", + "contractAddress": null, + "feePayer": "0x33f524631e573329a550296f595c820d6c65213f", + "feePayerSignatures": [ + { + "V": "0x25", + "R": "0xa3e40598b67e2bcbaa48fdd258b9d1dcfcc9cc134972560ba042430078a769a5", + "S": "0x6707ea362e588e4e5869cffcd5a058749d823aeff13eb95dc1146faff561df32" + } + ], + "feeRatio": "0x58", + "from": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", + "gas": "0x174876e800", + "gasPrice": "0x5d21dba00", + "gasUsed": "0xd0fc", + "input": "0xf8ad80b8aaf8a8a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002a00000000000000000000000000000000000000000000000000000000000000003a00000000000000000000000000000000000000000000000000000000000000004058006", + "logs": [], + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "nonce": "0x12", + "senderTxHash": "0xa0670c01fe39feb2d2442adf7df1957ade3c5abcde778fb5edf99c80c06aa53c", + "signatures": [ + { + "V": "0x26", + "R": "0xc612a243bcb3b98958e9cce1a0bc0e170291b33a7f0dbfae4b36dafb5806797d", + "S": "0xc734423492ecc21cc53238147c359676fcec43fcc2a0e021d87bb1da49f0abf" + } + ], + "status": "0x1", + "transactionHash": "0xc01a7c3ece18c115b58d7747669ec7c31ec5ab031a88cb49ad85a31f6dbbf915", + "transactionIndex": "0xb", + "type": "TxTypeFeeDelegatedChainDataAnchoringWithRatio", + "typeInt": 74 +} +``` diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/transactions.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/transactions.md new file mode 100644 index 000000000000..720c2bd96c4c --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/transactions/transactions.md @@ -0,0 +1,49 @@ +# トランザクションの実装 + +本ガイドは、Kaiaネットワーク上でのトランザクション実装の包括的な概要を提供し、様々なトランザクションタイプ、エンコーディング、署名、ネットワークインタラクションをカバーする。 + +## カイア トランザクション コンポーネント + +カイアの取引には一般的に以下の要素が含まれる： + +| コンポーネント | 説明 | +| :------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| から | 送信者の住所。 キー・ペアとアドレスの分離のため、ほとんどのKaiaトランザクション・タイプに必要である。 | +| へ\`。 | 送金された金額を受け取る口座アドレス。 | +| 値 | 譲渡される`kei`のKAIAの量。 | +| 入力\` | トランザクションの実行に使用される、トランザクションに添付されたデータ。 | +| `v`, `r`, `s` | 受信者が送信者のアドレスを取得するために送信者が生成した暗号署名。 | +| 一度たりとも | 送信者のトランザクションを一意に識別するために使用される値。 同じnonceを持つ2つのトランザクションが送信者によって生成された場合、1つだけが実行される。 | +| ガス | トランザクションが使用できる取引手数料の上限額。 | +| ガス料金 | 送信者がトークンで支払う金額を得るための乗数。 送信者が支払うトークンの金額は `gas` ⑭ `gasPrice` によって計算される。 For example, the sender will pay 10 KLAY for a transaction fee if gas is 10 and gasPrice is 10^18. KAIAのユニットについては[こちら](../../learn/token-economics/kaia-native-token.md#units-of-kaia)を参照されたい。 | + +## 署名検証 + +Kaiaはキー・ペアをアドレスから切り離すため、署名の検証は一般的なブロックチェーンとは異なる。 `from`フィールドは送信者を特定するために非常に重要である。 `from`アドレスに関連付けられた[AccountKey](../../learn/accounts.md#account-key)は、署名の検証に使用される。 + +## 手数料の委任とSenderTxHash + +カイアの手数料委任機能は、第三者が取引手数料を支払うことを可能にする。 これには2つの署名が必要である。1つは差出人の署名、もう1つは手数料支払者の署名である。 `SenderTxHash`は、料金委譲されたトランザクションを追跡するために重要である。 これは、手数料支払者の情報を含まない\*トランザクションのハッシュであり、手数料支払者が署名する前に送信者がトランザクションを追跡することを可能にする。 送信者は `SenderTxHash` を使用して、[kaia_getTransactionBySenderTxHash](../../references/json-rpc/kaia/get-transaction-by-sender-tx-hash) RPC メソッドでトランザクション全体を取得することができる。 + +## トランザクションの種類 + +一般的なブロックチェーンプラットフォームが単一のトランザクションタイプを提供するのに対し、Kaiaは複数のトランザクションタイプを提供し、新しい機能とメモリフットプリントとパフォーマンスの最適化によってトランザクションを強化します。 次の表は、カイアで利用可能な取引タイプの概要を示しています： + +| | ベーシック | 手数料の委任 | 料金の一部委任 | +| :--------------------- | :---------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | +| Legacy | [TxTypeLegacyTransaction](./basic.md#txtypelegacytransaction) | N/A | N/A | +| ValueTransfer | [TxTypeValueTransfer](./basic.md#txtypevaluetransfer) | [TxTypeFeeDelegatedValueTransfer](./fee-delegation.md#txtypefeedelegatedvaluetransfer) | [TxTypeFeeDelegatedValueTransferWithRatio](./partial-fee-delegation.md#txtypefeedelegatedvaluetransferwithratio) | +| ValueTransferMemo | [TxTypeValueTransferMemo](./basic.md#txtypevaluetransfermemo) | [TxTypeFeeDelegatedValueTransferMemo](./fee-delegation.md#txtypefeedelegatedvaluetransfermemo) | [TxTypeFeeDelegatedValueTransferMemoWithRatio](./partial-fee-delegation.md#txtypefeedelegatedvaluetransfermemowithratio) | +| SmartContractDeploy | [TxTypeSmartContractDeploy](./basic.md#txtypesmartcontractdeploy) | [TxTypeFeeDelegatedSmartContractDeploy](./fee-delegation.md#txtypefeedelegatedsmartcontractdeploy) | [TxTypeFeeDelegatedSmartContractDeployWithRatio](./partial-fee-delegation.md#txtypefeedelegatedsmartcontractdeploywithratio) | +| SmartContractExecution | [TxTypeSmartContractExecution](./basic.md#txtypesmartcontractexecution) | [TxTypeFeeDelegatedSmartContractExecution](./fee-delegation.md#txtypefeedelegatedsmartcontractexecution) | [TxTypeFeeDelegatedSmartContractExecutionWithRatio](./partial-fee-delegation.md#txtypefeedelegatedsmartcontractexecutionwithratio) | +| AccountUpdate | [TxTypeAccountUpdate](./basic.md#txtypeaccountupdate) | [TxTypeFeeDelegatedAccountUpdate](./fee-delegation.md#txtypefeedelegatedaccountupdate) | [TxTypeFeeDelegatedAccountUpdateWithRatio](./partial-fee-delegation.md#txtypefeedelegatedaccountupdatewithratio) | +| Cancel | [TxTypeCancel](./basic.md#txtypecancel) | [TxTypeFeeDelegatedCancel](./fee-delegation.md#txtypefeedelegatedcancel) | [TxTypeFeeDelegatedCancelWithRatio](./partial-fee-delegation.md#txtypefeedelegatedcancelwithratio) | +| ChainDataAnchoring | [TxTypeChainDataAnchoring](./basic.md#txtypechaindataanchoring) | [TxTypeFeeDelegatedChainDataAnchoring](./fee-delegation.md#txtypefeedelegatedchaindataanchoring) | [TxTypeFeeDelegatedChainDataAnchoringWithRatio](./partial-fee-delegation.md#txtypefeedelegatedchaindataanchoringwithratio) | + +## 実施内容 + +- **RLPエンコーディング:** トランザクションは、提出前にRLP（Recursive Length Prefix）エンコーディングを使用してシリアライズされます。 +- **署名：** トランザクションは、真正性を保証するために、[署名アルゴリズムを指定、例：ECDSA] を使用して署名されます。 +- **例とRPC出力：** このセクションでは、各トランザクション・タイプについて、実用的な例と予想されるRPC出力を提供する。 (注意: `TxTypeValueTransfer` は追加データなしでKAIAを送信するが、 `TxTypeValueTransferMemo` は転送と一緒に短いメモフィールドを含めることができる)。 + +これらのコンポーネントと実装の詳細を理解することで、開発者はKaiaネットワーク上で効果的にアプリケーションを構築することができる。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/buy-me-a-coffee.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/buy-me-a-coffee.md index b30c990d12d7..b69b175f2de8 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/buy-me-a-coffee.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/buy-me-a-coffee.md @@ -1,83 +1,83 @@ -# Build a Buy-Me-A-Coffee DApp +# Buy-Me-A-Coffee DAppの構築 -## Table of Contents +## 目次 -- [1. Project Setup](#1-project-setup) -- [2. Creating a Buy Me A Coffee Smart Contract](#2-creating-a-buy-me-a-coffee-smart-contract) -- [3. Testing the contract’s functionalities using scripts](#3-testing-the-contracts-functionalities-using-scripts) -- [4. Deploying BMC Smart contract to Klaytn Testnet ](#4-deploying-bmc-smart-contract) -- [5. Building the BMC Frontend with React and Web3Onboard](#5-building-the-bmc-frontend-with-react-and-web3onboard) -- [6. Deploying Frontend code on IPFS using Fleek](#6-deploying-frontend-code-on-ipfs-using-fleek) -- [7. Conclusion](#7-conclusion) +- [1. プロジェクト・セットアップ](#1-project-setup) +- [2. コーヒーを買うスマートコントラクトの作成](#2-creating-a-buy-me-a-coffee-smart-contract) +- [3. スクリプトを使った契約の機能テスト](#3-testing-the-contracts-functionalities-using-scripts) +- [4. カイア・テストネットへのBMCスマート・コントラクトの導入 ](#4-deploying-bmc-smart-contract) +- [5. ReactとWeb3OnboardによるBMCフロントエンドの構築](#5-building-the-bmc-frontend-with-react-and-web3onboard) +- [6. Fleekを使ってフロントエンドのコードをIPFSにデプロイする](#6-deploying-frontend-code-on-ipfs-using-fleek) +- [7. 結論](#7-conclusion) -## Introduction +## はじめに -Buy Me a Coffee (BMC) is a platform where creators get monetary support and donations from their fans or audience. These creators could be writers, artists, musicians, video creators, et al. With the help of this platform, fans may play a significant role in the success stories of creators, audiences can express their appreciation for the job that creators accomplish, and creators can monetize their work. +Buy Me a Coffee（BMC）は、クリエイターがファンや視聴者から金銭的な支援や寄付を得るプラットフォームである。 このプラットフォームの助けを借りて、ファンはクリエイターのサクセスストーリーに重要な役割を果たすことができ、観客はクリエイターが成し遂げた仕事に対して感謝の意を表すことができ、クリエイターは自分の作品を収益化することができる。 -On a high level, Buy-me-a-Coffee simplifies the process of accepting payments for creators and enhances interactions between creators and audiences. These and more are some of the exciting features on the BMC platform. On the bright side, imagine this platform on the blockchain. Creators will now get access to more benefits, such as: +高いレベルでは、Buy-me-a-Coffeeは、クリエイターの支払いを受け入れるプロセスを簡素化し、クリエイターとオーディエンスの間の相互作用を強化する。 この他にも、BMCプラットフォームにはエキサイティングな機能がある。 明るい面としては、このプラットフォームをブロックチェーン上で想像してみてほしい。 クリエイターは、より多くの特典を利用できるようになった： -- Complete payment, as opposed to traditional BMC, which charges 5% on any support received by the creator. -- Transparency because all transactions are recorded on the blockchain. -- Directly receive support fees from fans without any intermediary. -- Decentralization, i.e., there is no central authority controlling the platform. +- 従来のBMCが、クリエイターが受けたサポートに対して5％を請求するのとは対照的に、完全な支払い。 +- すべての取引がブロックチェーンに記録されるため、透明性が高い。 +- ファンからの支援金を仲介なしに直接受け取ることができる。 +- 分散化、つまり、プラットフォームをコントロールする中央当局が存在しない。 -In this tutorial. you will build a decentralized version of the Buy Me a Coffee (BMC) platform (frontend + smart contract). This platform will be a minimalistic implementation of the traditional BMC platform where supporters can tip you, and you will be able to withdraw any tips that are delivered to the BMC smart contract as the contract's owner. Supporters will be able to send test KLAY and lovely messages together in a coffee transaction using this site. +このチュートリアルでは あなたは、Buy Me a Coffee (BMC)プラットフォームの分散型バージョン（フロントエンド＋スマートコントラクト）を構築します。 このプラットフォームは、従来のBMCプラットフォームの最小限の実装となり、支援者はあなたにチップを渡すことができ、あなたは契約の所有者としてBMCスマートコントラクトに届けられたチップを引き出すことができる。 Supporters will be able to send test KLAY and lovely messages together in a coffee transaction using this site. -By the end of this guide, you will have used the following to create this dApp: +このガイドが終わるまでに、このdAppを作成するために以下を使用することになる： -- Solidity: to write the BMC smart contract -- NextJs and Tailwind: for building a frontend website for our BMC dApp -- Web3Onboard: to enable multiple wallet connections to Klaytn Testnet Baobab. -- Fleek: with Fleek we can host our BMC dApp on IPFS. +- Solidity：BMCスマートコントラクトを記述する +- NextJsとTailwind：BMC dAppのフロントエンドウェブサイト構築用 +- Web3Onboard: Kaia Testnet Kairosへの複数のウォレット接続を可能にする。 +- Fleek：Fleekを使えば、IPFS上でBMC dAppをホストできる。 -## Prerequisites +## 前提条件 -To complete this tutorial, you will need: +このチュートリアルを完了するには、以下のものが必要です： - [Node.js](https://nodejs.org/en/download/package-manager) -- Familiarity with Javascript and React basics such as hooks etc -- Installation of the necessary wallets, such as [Coinbase Wallet](https://www.coinbase.com/wallet/downloads), and [Metamask Wallet](https://metamask.io/download/) -- Test KAIA from [Faucet](https://faucet.kaia.io). -- RPC Endpoint: you can obtain this from one of the supported [endpoint providers](../../references/public-en.md). -- Creation of an account on [Fleek](https://app.fleek.co/). +- フックなど、JavascriptとReactの基本に精通していること +- Coinbase Wallet](https://www.coinbase.com/wallet/downloads)、【Metamask Wallet](https://metamask.io/download/)など、必要なウォレットのインストール。 +- [Faucet](https://faucet.kaia.io)からKAIAをテストする。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](../../references/public-en.md)のいずれかから取得できます。 +- Fleek](https://app.fleek.co/)にアカウント作成。 -## 1. Project Setup +## 1. プロジェクト設定 -In this section, we will initialize our project folder. This folder will contain two separate folders: +このセクションでは、プロジェクト・フォルダーを初期化します。 このフォルダには2つの別々のフォルダが含まれる： -1. frontend folder - which contains the code for the frontend implementation of our dApp -2. smart-contract folder - which contains the smart contract code for our BMC dApp. +1. frontendフォルダ - 私たちのdAppのフロントエンド実装のコードが含まれています。 +2. smart-contractフォルダ - BMC dAppのスマートコントラクトコードが格納されています。 -To create our project folder, paste this code in your terminal +プロジェクトフォルダを作成するには、次のコードをターミナルに貼り付けます。 ```bash mkdir BuyMeACoffee cd BuyMeACoffee ``` -### 1.1. Frontend folder +### 1.1. フロントエンドフォルダ -This folder contains the tools to build our project frontend website. For the sake of this guide, we will be using Next's [create-next-app](https://nextjs.org/docs/api-reference/create-next-app) utility to bootstrap our Next.js and Tailwind CSS project. Follow the steps below to install the necessary dependencies and get our frontend folder created: +このフォルダには、プロジェクトのフロントエンドウェブサイトを構築するためのツールが含まれています。 このガイドでは、Next.jsとTailwind CSSプロジェクトをブートストラップするために、Nextの[create-next-app](https://nextjs.org/docs/api-reference/create-next-app)ユーティリティを使用します。 以下の手順に従って、必要な依存関係をインストールし、フロントエンドフォルダを作成します： -#### Step 1 - Creating a frontend folder +#### ステップ1 - フロントエンドフォルダの作成 -Paste the code below in your BuyMeACoffee folder to create a frontend folder using create-next-app utility: +以下のコードをBuyMeACoffeeフォルダに貼り付け、create-next-appユーティリティを使ってフロントエンドフォルダを作成します： ```bash npx create-next-app frontend cd frontend ``` -#### Step 2 - Downloading the Tailwind dependencies and setting up its config +#### ステップ2 - Tailwindの依存関係のダウンロードと設定 ```bash npm install -D tailwindcss postcss autoprefixer npx tailwindcss init -p ``` -#### Step 3 - Modifying `tailwind.config.js` +#### ステップ3 - `tailwind.config.js` を修正する -Navigate to the `tailwind.config.js` file and replace with the code below: +`tailwind.config.js`ファイルに移動し、以下のコードに置き換える： ```js module.exports = { @@ -92,9 +92,9 @@ module.exports = { } ``` -#### Step 4 - Replacing the code in styles/global.css +#### ステップ4 - styles/global.cssのコードを置き換える -Navigate to the styles/global.css file and replace with the code below: +styles/global.cssファイルに移動し、以下のコードに置き換える： ```css @tailwind base; @@ -102,15 +102,15 @@ Navigate to the styles/global.css file and replace with the code below: @tailwind utilities; ``` -We have successfully set up our frontend project folder. More will be discussed later on. The next step is to set up the smart contract folder. +フロントエンドのプロジェクトフォルダのセットアップが完了しました。 詳しくは後述する。 次のステップは、スマート・コントラクト・フォルダーを設定することだ。 -### 1.2. Smart Contract Folder +### 1.2. スマートコントラクトフォルダ -This folder contains the smart contract for our BuyMeACoffee functionality. Follow the steps below to install the necessary dependencies and get our smart contract folder created: +このフォルダには、BuyMeACoffee機能のスマートコントラクトが含まれています。 以下の手順に従って、必要な依存関係をインストールし、スマート・コントラクト・フォルダーを作成する： -#### Step 1 - Creating the smart contract folder +#### ステップ1 - スマート・コントラクト・フォルダーの作成 -To create this folder, navigate to the project directory: BuyMeACoffee and create a smart-contract folder by running the command below: +このフォルダを作成するには、プロジェクト・ディレクトリに移動します：BuyMeACoffeeに移動し、以下のコマンドを実行してsmart-contractフォルダを作成します： ```bash cd .. @@ -118,15 +118,15 @@ mkdir smart-contract cd smart-contract ``` -#### Step 2 - Generating a hardhat project template +#### ステップ2 - ハードハット・プロジェクト・テンプレートの作成 -This template is suitable for writing, testing and deploying smart contracts. Firstly, start a new npm project by running the code below in your terminal: +このテンプレートは、スマート・コントラクトの記述、テスト、デプロイに適している。 まず、ターミナルで以下のコードを実行して、新しいnpmプロジェクトを開始する： ```bash npm init -y ``` -This should create a package.json file for you that looks like this: +これで、次のようなpackage.jsonファイルが作成されるはずだ： ```json { @@ -143,7 +143,7 @@ This should create a package.json file for you that looks like this: } ``` -Then, install hardhat and other dependencies such as hardhat-toolbox and dotenv. To do so, replace your package.json file with the code below: +次に、hardhatと、hardhat-toolboxやdotenvなどの依存関係をインストールする。 そのためには、package.jsonファイルを以下のコードで置き換えてください： ```json { @@ -158,29 +158,29 @@ Then, install hardhat and other dependencies such as hardhat-toolbox and dotenv. } ``` -Finally, run `npm install` in your terminal. +最後に、ターミナルで `npm install` を実行する。 -After successfully installing all the dependencies(hardhat, hardhat-toolbox, dotenv), you can confirm hardhat installation by: +すべての依存関係（hardhat、hardhat-toolbox、dotenv）のインストールに成功したら、以下の方法でhardhatのインストールを確認できる： -a. Checking the current version: +a. 現在のバージョンをチェックする： ```bash npx hardhat --version ``` -Your console should print out the current version installed which in our case is **2.14.0.** +コンソールには、インストールされている現在のバージョンが印刷されるはずです。私たちの場合は**2.14.0**です。 -b. Viewing your project directory. Your current directory should include: +b. プロジェクトディレクトリの表示 あなたのカレント・ディレクトリは、以下を含むべきである： -- **contracts/** – this is the folder containing the smart contract. -- **scripts/** – this folder contains code that deploys your contracts on the blockchain network -- **test/** – this folder contains all unit tests that test your smart contract -- **hardhat.config.ts** – this file contains configurations important for the work of Hardhat and - the deployment of smart contracts. +- **contracts/**-これはスマート・コントラクトを含むフォルダである。 +- **スクリプト/** - このフォルダには、あなたのコントラクトをブロックチェーン・ネットワーク上にデプロイするコードが含まれています。 +- **test/** - このフォルダには、スマートコントラクトをテストするすべてのユニットテストが含まれています。 +- **hardhat.config.ts** - このファイルには、Hardhatの作業に重要な設定が含まれており、 + 、スマート・コントラクトのデプロイが行われます。 -## 2. Creating a Buy Me A Coffee Smart Contract +## 2. コーヒーを買うスマートコントラクトの作成 -In this section we will be creating the smart contract that houses the BMC functionality. To get started, navigate to your **contracts** folder, create a new file named `BuyMeACoffee.sol` and paste this code below: +このセクションでは、BMC機能を格納するスマート・コントラクトを作成する。 `BuyMeACoffee.sol`という名前の新しいファイルを作成し、以下のコードを貼り付けてください： ```solidity // SPDX-License-Identifier: UNLICENSED @@ -243,37 +243,37 @@ contract BuyMeACoffee { } ``` -Let's quickly go over what each line of code does: +各コードが何をするのか、手短に説明しよう： -The **NewCoffee** event is emitted when a buyCoffee function is executed. It logs out the address of the sender, the name of the sender, the message sent, and the timestamp. +BuyCoffee関数が実行されると、**NewCoffee**イベントが発生します。 送信者のアドレス、送信者の名前、送信されたメッセージ、タイムスタンプがログアウトされる。 -Next is the **owner** variable, which represents the contract deployer. We then set the **msg.sender** to be the owner of the contract in our constructor. +次に**owner**変数であるが、これはコントラクトのデプロイ先を表す。 次に、コンストラクタで**msg.sender**をコントラクトのオーナーに設定する。 -The **coffeeId** was created to keep track of the coffee transaction created. +**coffeeId**は、作成されたコーヒーのトランザクションを追跡するために作成された。 -Subsequently we declared a **buyMeACoffee struct**, which stores all the data related to a coffee transaction; address sender, string name, uint timestamp, string message. We then mapped this struct to an id using the **idToBuyCoffee** variable. +buyMeACoffee構造体\*\*を宣言し、コーヒー取引に関連するすべてのデータ（送信者アドレス、文字列名、uintタイムスタンプ、文字列メッセージ）を格納する。 次に、**idToBuyCoffee**変数を使用して、この構造体をidにマッピングしました。 -The buyCoffee function is the core implementation of BMC smart contract. It is a payable function which takes in two parameters, the name and address of the sender. It checks if the KLAY amount sent in is greater than zero. Next it increments the coffeeId, then it adds the coffee tx or info to the blockchain. Finally it emits a NewCoffee event, which entails the details of the coffee tx. +buyCoffee機能は、BMCスマートコントラクトのコア実装である。 これは支払い可能な関数で、送信者の名前と住所の2つのパラメータを受け取る。 It checks if the KLAY amount sent in is greater than zero. 次に coffeeId をインクリメントし、コーヒーの Tx や情報をブロックチェーンに追加する。 最後に、NewCoffeeイベントを発行し、コーヒーtxの詳細を伝える。 -We created a **withdraw()** function to withdraw the total balance of the contract (`address(this).balance`) to the owner. +契約残高の合計（`address(this).balance`）をオーナーに引き出すために、\*\*withdraw()\*\*関数を作りました。 -Finally, a **getAllCoffee()** function was created. It returns all the coffee transactions created overtime. +最後に、\*\*getAllCoffee()\*\*関数が作られた。 これは、時間外に作成されたすべてのコーヒー・トランザクションを返す。 -Now that we have completed writing our BMC smart contract, the next step is to test the functionalities of our smart contract, deploy and interact with the smart contract on **Klaytn Testnet Baobab**. +BMCスマートコントラクトの記述が完了したので、次のステップはスマートコントラクトの機能をテストし、**Kaia Testnet Kairos**にデプロイしてスマートコントラクトとやり取りすることです。 -## 3. Testing the contract’s functionalities using scripts +## 3. スクリプトを使った契約書の機能テスト -In this section, we will be writing scripts to test the functionality of our smart contract . To get started, navigate to your scripts folder, create a new file named `bmc-sample.js` and paste the following code in it: +このセクションでは、スマート・コントラクトの機能をテストするためのスクリプトを書く。 まず、scriptsフォルダに移動し、`bmc-sample.js`という名前のファイルを新規作成し、以下のコードを貼り付けます： ```js const hre = require("hardhat"); -// Logs the KLAY balances of a specific address. +// Logs the KAIA balances of a specific address. async function getBalance(address) { const balanceBigInt = await hre.ethers.provider.getBalance(address); return hre.ethers.utils.formatEther(balanceBigInt) } -// Logs the KLAY balances for a list of addresses. +// Logs the KAIA balances for a list of addresses. async function getBalances(addresses) { let idx = 0; for (const address of addresses) { @@ -333,27 +333,27 @@ main().catch((error) => { }); ``` -As always, lets go over what each line of code does: +いつものように、各コード行が何をするのかを説明しよう： -You will notice that at the top of the code, there exist some helper functions for getting the balances of both a single address and multiple addresses. Also in the code exists the main function which houses the functionality of testing our smart contract. +コードの先頭には、単一アドレスと複数アドレスの残高を取得するためのヘルパー関数がいくつか用意されていることにお気づきだろう。 このコードには、スマート・コントラクトをテストする機能を持つメイン関数も含まれている。 -Let's do a walk through of the code in the **main()** function. +では、\*\*main()\*\*関数のコードを一通り見てみよう。 -First we set the list of accounts (owner, tipper1, tipper2, tipper3) for test purposes by calling `await hre.ethers.getSigners()` +まず、`await hre.ethers.getSigners()`を呼び出して、テスト用のアカウントリスト(owner, tipper1, tipper2, tipper3)を設定します。 -Next we created a contract instance and deployed it. In this case the BuyMeACoffee.sol contract. +次にコントラクト・インスタンスを作成し、デプロイした。 この場合はBuyMeACoffee.solの契約である。 -Then, we set a list of addressees, checked their balances using the **getBalances()** function. We then called the **buyCoffee** function on three different instances. Next we checked each addresses balance after the coffee transaction. +次に、宛先のリストを設定し、**getBalances()**関数を使って残高をチェックする。 次に、3つの異なるインスタンスで**buyCoffee**関数を呼び出した。 次に、コーヒー取引後に各住所の残高をチェックした。 -That said, we then called the **withdraw** function to withdraw all funds to the owner address. Next we checked the addresses balance after withdrawal. +つまり、次に**withdraw**関数を呼び出し、すべての資金をオーナーのアドレスに引き出した。 次に、出金後のアドレスの残高を確認した。 -Finally, we got all the coffee transactions in the smart contract by calling the **getAllCoffee()** function. To see the script in action, run the command below: +最後に、\*\*getAllCoffee()\*\*関数を呼び出すことで、スマート・コントラクト内のすべてのコーヒー・トランザクションを取得した。 スクリプトの動作を見るには、以下のコマンドを実行する： ```bash npx hardhat run scripts/bmc-coffee.js ``` -You should have an output in your terminal that looks like this: +ターミナルに次のような出力が出るはずだ： ```bash Ayomitans-MacBook-Pro:smart-contract oxpampam$ npx hardhat run scripts/bmc-sample.js @@ -376,32 +376,32 @@ At 1686307886, Bob, with 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC, said: "Hi A At 1686307887, Japhet, with 0x90F79bf6EB2c4f870365E785982E1f101E93b906, said: "Hi Ox" ``` -## 4. Deploying BMC Smart contract +## 4. BMCスマートコントラクトの導入 -### 4.1 Deploying BMC Smart contract to Klaytn Testnet +### 4.1 BMCスマートコントラクトをKaia Testnetにデプロイする -After successfully testing the functionalities of our BMC smart contract, let’s proceed to deploy to the Klaytn Testnet Baobab in the following steps: +BMCスマートコントラクトの機能テストに成功したら、次のステップでKaia Testnet Kairosにデプロイしましょう： -#### Step 1 - Creating a .env file +#### ステップ1 - .envファイルの作成 -Now create your .env file in the project folder. This file helps us load environment variables from a .env file into process.env. +プロジェクト・フォルダーに.envファイルを作成する。 このファイルは、.envファイルからprocess.envに環境変数をロードするのに役立つ。 -Paste this command in your terminal to create a .env file +以下のコマンドをターミナルに貼り付け、.envファイルを作成する。 ```bash touch .env ``` -After creating your file, lets configure our .env file to look like this: +ファイルを作成したら、.envファイルを次のように設定しよう： ```bash -KAIROS_TESTNET_URL= "Your RPC URL" -PRIVATE_KEY= "your private key copied from metamask wallet" +KAIROS_TESTNET_URL= "あなたのRPC URL" +PRIVATE_KEY= "メタマスク・ウォレットからコピーしたあなたの秘密鍵" ``` -#### Step 2 - Setting up Hardhat Configs +#### ステップ2 - ハードハットの設定 -Paste this configurations in your hardhat.config.js file +この設定をhardhat.config.jsファイルに貼り付けます。 ``` require("@nomicfoundation/hardhat-toolbox"); @@ -421,9 +421,9 @@ module.exports = { }; ``` -#### Step 3 - Creating deployment scripts +#### ステップ3 - デプロイメントスクリプトの作成 -To create a new deployment script that deploys this smart contract to a specified network, create a new file scripts/deploy.js and paste in the code below: +このスマート・コントラクトを指定したネットワークにデプロイする新しいデプロイ・スクリプトを作成するには、新しいファイルscripts/deploy.jsを作成し、以下のコードを貼り付ける： ```js const hre = require("hardhat"); @@ -441,23 +441,23 @@ main().catch((error) => { }); ``` -Now that we have our configurations all set, let’s deploy to Klaytn Testnet Baobab by running the command below: +これで設定がすべて整ったので、以下のコマンドを実行してKaia Testnet Kairosにデプロイしてみよう： ```bash npx hardhat run scripts/deploy.js --network baobab ``` -Once the contract deploys successfully, your terminal should look like this: +コントラクトが正常にデプロイされると、ターミナルは次のようになるはずだ： ```bash BuyMeACoffee Contract Address 0x0bEd1ed7B205d8c18e38A20b5BaB6e265A96d1AC ``` -Congratulations on deploying your BMC smart contract on Klaytn Baobab Network! You can verify this transaction on Klaytnscope by pasting your address in the search field. +BMCスマートコントラクトのKaia Kairos Networkへのデプロイおめでとうございます！ 検索フィールドにあなたのアドレスを貼り付けると、Kaiascopeでこの取引を確認することができます。 -### 4.2 Interacting with BMC Smart Contract +### 4.2 BMCスマートコントラクトとの対話 -In this section, you will learn how to use hardhat scripts to withdraw the coffee tips sent into the smart contract. To get started, create a new file `withdraw.js` in your scripts folder and paste the code below: +このセクションでは、スマートコントラクトに送られたコーヒーチップを引き出すために、ハードハットスクリプトを使用する方法を学びます。 まず、scriptsフォルダに新規ファイル`withdraw.js`を作成し、以下のコードを貼り付けます： ```js const hre = require("hardhat"); @@ -486,8 +486,8 @@ async function main() { const balanceBefore = await getBalance(signer.address); const contractBalance = await getBalance(BuyMeACoffee.address); - console.log(`Owner balance before withdrawing tips: ${balanceBefore} KLAY`); - console.log(`Contract balance before withdrawing tips: ${contractBalance} KLAY`); + console.log(`Owner balance before withdrawing tips: ${balanceBefore} KAIA`); + console.log(`Contract balance before withdrawing tips: ${contractBalance} KAIA`); // Withdraw funds if there are funds to withdraw. if (contractBalance !== "0.0") { @@ -496,7 +496,7 @@ async function main() { await withdrawCoffeTxn.wait(); // check owner's balance after withdrawing coffee tips const balanceAfter = await getBalance(signer.address); - console.log(`Owner balance after withdrawing tips ${balanceAfter} KLAY`); + console.log(`Owner balance after withdrawing tips ${balanceAfter} KAIA`); } else { console.log("no funds to withdraw!"); } @@ -509,17 +509,17 @@ main().catch((error) => { }); ``` -As you can see from the code above, having instantiated the BMC contract, the scripts will execute the withdrawCoffeTips function only when the contract balance is greater than zero. Makes sense right? +上のコードからわかるように、BMC 契約をインスタンス化すると、スクリプトは契約残高がゼロより大きいときだけ withdrawCoffeTips 関数を実行します。 理にかなっているだろう？ -Yes! In the event where the contract has no funds, it prints "No funds to withdraw" hence saving us some gas from contract invocation. +そうだ！ コントラクトに資金がない場合、「引き出す資金がありません」と表示されるため、コントラクトを起動する手間が省ける。 -To see this in action, lets run the script below: +これを実際に見てみるために、以下のスクリプトを実行してみよう： ```bash npx hardhat run scripts/withdraw.js --network baobab ``` -On successful execution of the scripts, your terminal should look like this: +スクリプトの実行に成功すると、ターミナルは次のようになるはずだ： ```bash Ayomitans-MacBook-Pro:smart-contract oxpampam$ npx hardhat run scripts/withdraw.js --network baobab @@ -531,46 +531,46 @@ Owner balance after withdrawing tips 157.83298835 KLAY You can see from the output that the owner balance increased by 2 KLAY after withdrawing the coffee tips. -Now that we have our contract deployed and all functionalities tested, it is time to build out the frontend. +契約がデプロイされ、すべての機能がテストされたので、次はフロントエンドを構築する番だ。 -The frontend will bring the BMC functionality to live i.e we can now visualize how we interact with the BMC smart contract. +つまり、BMCスマートコントラクトとどのようにやりとりするかを可視化できるようになる。 -## 5. Building the BMC Frontend with React and Web3Onboard +## 5. ReactとWeb3OnboardでBMCフロントエンドを構築する -In this section, we will be building our dApp frontend website with Next.js and Web3Onbaord. To get started, you have to navigate to the frontend folder previously created. +このセクションでは、Next.jsとWeb3Onbaordを使ってdAppのフロントエンドウェブサイトを構築します。 開始するには、以前に作成したフロントエンドフォルダに移動する必要があります。 ```bash cd .. cd frontend ``` -The next step is to install the necessary dependencies to get our BMC frontend website up and running. The following are the packages to be installed: +次のステップは、BMCフロントエンドのウェブサイトを立ち上げて実行するために必要な依存関係をインストールすることだ。 インストールするパッケージは以下の通り： -1. Web3Onboard packages: Web3-Onboard is a chain-agnostic wallet library that supports multi-wallet compatibility in your dApp built on EVM-compatible networks like Klaytn Blockchain. -2. ethers.js: Web3-Onboard provider can be used with libraries like [ethers.js](https://docs.ethers.org/v6/) and[web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html). In this guide, we will use ethers.js to make Klaytn blockchain calls like getting the user's account, fetch balance, sign transaction, send transaction, read from and write to the smart contract. +1. Web3Onboardパッケージ：Web3-Onboardはチェーンに依存しないウォレットライブラリで、Kaia BlockchainのようなEVM互換ネットワーク上に構築されたdAppでマルチウォレットの互換性をサポートします。 +2. ethers.jsを使用しています：Web3-Onboardプロバイダは、[ethers.js](https://docs.ethers.org/v6/)や[web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html)のようなライブラリで使用することができます。 このガイドでは、ethers.jsを使用して、ユーザーのアカウントの取得、残高の取得、トランザクションの署名、トランザクションの送信、スマートコントラクトからの読み取り、スマートコントラクトへの書き込みなどのKaiaブロックチェーンの呼び出しを行います。 -Important Note: We need to edit 2 files in the frontend/pages folder +重要：frontend/pagesフォルダ内の2つのファイルを編集する必要があります。 - **_app.js** - **index.js** -### 5.1 Setting up Web3Onboard Provider and Wallet Modules +### 5.1 Web3Onboardプロバイダとウォレットモジュールのセットアップ -#### Step 1 - Installing @web3-onboard/react +#### ステップ1 - @web3-onboard/reactをインストールする ```bash npm install @web3-onboard/react ``` -In your `_app.js` file, import the web3OnboardProvider and init function. More to be discussed later. +`_app.js`ファイルで、web3OnboardProviderとinit関数をインポートする。 詳細は後述する。 ```js import { Web3OnboardProvider, init } from '@web3-onboard/react' ``` -#### Step 2 - Installing and Instantiating Wallet Modules +#### ステップ2 - ウォレットモジュールのインストールとインスタンス化 -In this step, you can add as many wallets to be supported in your dApp using the wallet modules. But for this guide, you will add Coinbase Wallet, WalletConnect, Injected Wallets to your web3-Onboard implementation. +このステップでは、ウォレットモジュールを使ってdAppでサポートするウォレットをいくつでも追加できます。 しかし、このガイドでは、Coinbase Wallet、WalletConnect、Injected Walletsをweb3-Onboardの実装に追加します。 ```bash npm install @web3-onboard/coinbase // Coinbase Wallet @@ -578,7 +578,7 @@ npm install @web3-onboard/walletconnect // WalletConnect npm install @web3-onboard/injected-wallets // Used to connect to Metamask ``` -In your `_app.js` file, import and instantiate the wallet modules to integrate with your dApp. Note that each module has its own unique options parameters to pass in, such as a fallback JSON RPC URL or default chain ID. +`_app.js`ファイルで、dAppと統合するためのウォレットモジュールをインポートし、インスタンス化します。 各モジュールには、フォールバックJSON RPC URLやデフォルト・チェーンIDなど、渡すべき独自のオプション・パラメータがあることに注意してください。 ```js import coinbaseWalletModule from "@web3-onboard/coinbase"; @@ -590,19 +590,19 @@ const injected = injectedModule(); const modules = [coinbaseWalletSdk, walletConnect, injected]; ``` -#### Step 3 - Installing ethers +#### ステップ3 - エーテルの取り付け ```bash npm install --save ethers ``` -#### Step 4 - Instantiating Web3Onboard using the Web3OnboardProvider +#### ステップ4 - Web3OnboardProviderを使用してWeb3Onboardをインスタンス化する -Web3OnboardProvider provides a better way to manage global state. It simplifies wrapping the provider object around your App and the initialized Web3Onboard instance will be available in all children components. +Web3OnboardProviderは、グローバルな状態を管理するためのより良い方法を提供します。 これは、プロバイダオブジェクトをアプリにラップすることを簡素化し、初期化されたWeb3Onboardインスタンスは、すべての子コンポーネントで利用できるようになります。 -Init function initializes web3-Onboard and makes it available for all hooks to use. +Init関数はweb3-Onboardを初期化し、すべてのフックが使用できるようにします。 -To see this in action, paste the code below the previous code in your `_app.js `file: +これを実際に見るには、`_app.js `ファイルに、前のコードの下にあるコードを貼り付ける： ```js const ETH_MAINNET_RPC_URL = `https://eth-mainnet.g.alchemy.com/v2/demo`; @@ -654,11 +654,11 @@ export default function App({ Component, pageProps }) { } ``` -Having set up our _app.js file which grants our App a provider object and web3Onboard instance available in all children components, next is to build out front-end logic in our `index.js` file +アプリにプロバイダオブジェクトと、すべての子コンポーネントで利用可能な web3Onboard インスタンスを付与する _app.js ファイルをセットアップしたら、次は `index.js` ファイルでフロントエンドのロジックを構築します。 - Index.js -This page handles wallet connection and sending of coffee to the BMC smart contract which is to be withdrawn by the contract deployer. +このページは、BMCスマートコントラクトへのウォレット接続とコーヒーの送信を処理します。 ```js import React, { useEffect, useState } from 'react'; @@ -800,40 +800,40 @@ export default function Home() { } ``` -### Important notes from the code above +### 上記のコードからの重要な注意事項 -1. Get your contract ABI: The contract ABI specifies to the frontend code what functions are available to call on the smart contract. To get your contract abi, navigate to your smart-contract folder and copy the text in this file following this path **artifacts/contracts/BuyMeACoffee.sol/BuyMeACoffee.json**. Next we created a utils folder in the **frontend/src** folder. Then pasted it in a newly created file named BuyMeACoffee.json file. +1. コントラクトABIを取得する： コントラクトABIは、スマートコントラクト上でどのような関数を呼び出せるかをフロントエンドのコードに指定する。 契約アビを取得するには、スマート契約フォルダに移動し、以下のパスにしたがってこのファイルのテキストをコピーしてください。 次に、**frontend/src**フォルダにutilsフォルダを作成した。 そして、新しく作成したBuyMeACoffee.jsonファイルという名前のファイルに貼り付けた。 -2. Change BMC Contract address to the address of your BMC deployed contract. +2. BMC契約の住所を、BMCで展開されている契約の住所に変更します。 -Now if the app isn't already running, you can go to the shell and use `npm run dev` to start a local server to test out your changes. The website should load in a few seconds and UI should look like this: +アプリがまだ起動していなければ、シェルで `npm run dev` を使ってローカルサーバーを起動し、変更をテストすることができる。 ウェブサイトは数秒でロードされ、UIはこのようになるはずです： -Connect Wallet Page: +コネクトウォレットのページ ![](/img/build/tutorials/bmc-cw.png) ![](/img/build/tutorials/bmc-connect.png) -Frontend website to send coffee: +コーヒーを送るフロントエンドのウェブサイト： ![](/img/build/tutorials/bmc-frontend.png) -Now let's explore through our website and the code. +では、ウェブサイトとコードを見てみよう。 -You can already see from the above screenshot that when you first visit the dApp, it will ask you to connect a wallet. Next it pops up the list of available wallets initialized in the Web3Onboard instance. +上のスクリーンショットを見れば、dAppに初めてアクセスしたときに、ウォレットを接続するよう求められることがもうお分かりだろう。 次に、Web3Onboardインスタンスで初期化された利用可能なウォレットのリストがポップアップ表示されます。 -Then you select the wallet of your choice; from the image above, we selected MetaMask. Once you have connected your wallet, you get to see a UI component on the upper right of your website which contains the details of the connected wallet. Also on the page, you will see the coffee transaction form which contains the name and message of the sender, as well as the previous coffee paid into the smart contract by other visitors. +上の画像ではMetaMaskを選択しています。 ウォレットを接続すると、ウェブサイトの右上に接続されたウォレットの詳細を含むUIコンポーネントが表示されます。 また、このページにはコーヒー取引フォームが表示され、送信者の名前とメッセージ、他の訪問者がスマートコントラクトに支払った以前のコーヒーが表示されます。 -## 6. Deploying Frontend code on IPFS using Fleek +## 6. Fleekを使ってフロントエンドのコードをIPFSにデプロイする -Fleek is an infrastructure that enables us to build modern sites and apps on IPFS. With fleek your sites or app becomes permissionless, trustless, censorship resistant, and free of centralized gatekeepers. In this tutorial we will be deploying our Next js app to Fleek other than the traditional platforms like Vercel. -Yeah you got it! We are deploying a decentralized application to a decentralized hosting platform! +Fleekは、IPFS上にモダンなサイトやアプリを構築するためのインフラです。 fleekを使えば、あなたのサイトやアプリはパーミッションレス、トラストレス、検閲耐性、そして中央集権的なゲートキーパーから解放される。 このチュートリアルでは、Vercelのような従来のプラットフォームではなく、FleekにNext jsアプリをデプロイします。 +ああ、そうだね！ 私たちは分散型アプリケーションを分散型ホスティング・プラットフォームにデプロイしています！ -The following are the steps to deploy your BMC dApp to Fleek: +以下は、BMC dAppをFleekにデプロイする手順です： -1. Make sure to confirm these configurations in your frontend code: +1. フロントエンドのコードでこれらの設定を確認してください： - a. Open package.json and add in the following scripts: + a. package.jsonを開き、以下のスクリプトを追加する： ```js "scripts": { @@ -844,7 +844,7 @@ The following are the steps to deploy your BMC dApp to Fleek: } ``` - b. Paste the code below in your next.config.js file in the root directory: + b. ルート・ディレクトリにあるnext.config.jsファイルに、以下のコードを貼り付けます： ```js module.exports = { @@ -852,41 +852,41 @@ The following are the steps to deploy your BMC dApp to Fleek: }; ``` -For more information, visit this [guide](https://blog.fleek.co/posts/fleek-nextJS) +詳しくはこちらの[ガイド](https://blog.fleek.co/posts/fleek-nextJS)をご覧ください。 -2. Navigate to your dashboard on Fleek and click on **Add new Site** +2. Fleekのダッシュボードに移動し、**新しいサイトを追加**をクリックします。 ![](/img/build/tutorials/fleek-addsite.png) -3. Connect your GitHub account to access your repositories. +3. GitHubアカウントに接続してリポジトリにアクセスします。 ![](/img/build/tutorials/fleek-cg.png) -4. Select the repository you intend to deploy. +4. デプロイするリポジトリを選択します。 -5. On the next page,select the **Next Js** framework in the **Basic build setting** tab, and Fleek will automatically populate the other fields. +5. 次のページで、**基本ビルド設定**タブで**Next Js**フレームワークを選択すると、Fleekが自動的に他のフィールドに入力します。 -6. Click deploy site +6. サイトをクリック -7. In the event of an **npm WARN EBADENGINE Unsupported engine** as shown in the image below: +7. 以下の画像のように、**npm WARN EBADENGINE Unsupported engine**が発生した場合： ![](/img/build/tutorials/fleek-err.png) -Head over to **Deploy setting** in the **Deploy** tab and change the **Docker image Name** to **node:latest** as shown in the image below: +**Deploy**タブの**Deploy setting**に移動し、以下の画像のように**Docker image Name**を**node:latest**に変更します： ![](/img/build/tutorials/fleek-err-fix.png) -8. Now your site should build and deploy to IPFS easily. -9. Click the link generated to view your website. +8. これで、あなたのサイトは簡単にビルドされ、IPFSにデプロイされるはずだ。 +9. 生成されたリンクをクリックすると、ウェブサイトが表示されます。 ![](/img/build/tutorials/fleek-site-url.png) -Voila! We have our BMC dApp deployed and hosted on IPFS. +どうだ！ 私たちはBMC dAppをIPFS上にデプロイし、ホストしています。 -## 7. Conclusion +## 7. 結論 -If you’ve made it this far, congratulations! In this tutorial, you have learned how to create a full stack Buy Me A Coffee dApp using Solidity, NextJs, Web3Onboard and Fleek. This is the first step in creating a decentralized application hosted on a decentralized platform. +ここまで来たなら、おめでとう！ このチュートリアルでは、Solidity、NextJs、Web3Onboard、Fleek を使用してフルスタックの Buy Me A Coffee dApp を作成する方法を学びました。 これは、分散型プラットフォーム上でホストされる分散型アプリケーションを作成するための最初のステップである。 -From here, you could also explore some other options in your frontend like adding a new input field for the amount of coffee to be sent other than sending 1 KLAY statically. You can have access to the full codebase here on [github](https://github.com/ayo-klaytn/buy-me-a-coffee) and also test the website using this [link](https://spring-fog-0605.on.fleek.co/). +From here, you could also explore some other options in your frontend like adding a new input field for the amount of coffee to be sent other than sending 1 KLAY statically. [github](https://github.com/ayo-klaytn/buy-me-a-coffee)にあるコードベース全体にアクセスすることができ、この[リンク](https://spring-fog-0605.on.fleek.co/)を使ってウェブサイトをテストすることもできる。 -If you want more information, visit [Klaytn Docs](https://docs.klaytn.foundation/), [Web3Onboard Docs](https://onboard.blocknative.com/docs/modules/react), and [Fleek Docs](https://docs.fleek.co/tutorials/hosting/). If you have any questions, visit [Kaia Forum](https://devforum.kaia.io/). +より詳細な情報をお知りになりたい方は、[Kaia Docs](https://docs.klaytn.foundation/)、[Web3Onboard Docs](https://onboard.blocknative.com/docs/modules/react)、[Fleek Docs](https://docs.fleek.co/tutorials/hosting/)をご覧ください。 ご質問は[カイアフォーラム](https://devforum.kaia.io/)まで。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-metamask.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-metamask.mdx index af372557dea7..e00e6ef0067a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-metamask.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-metamask.mdx @@ -1,59 +1,59 @@ --- id: connecting-metamask -title: Connecting MetaMask to Kaia +title: メタマスクとカイアの接続 --- import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -# Connect MetaMask to Kaia +# メタマスクをカイアに接続 ![](/img/banners/kaia-metamask.png) -> **Note**: MetaMask is mostly used as a wallet for Ethereum, but it is also compatible with Kaia due to the identical address structures. Kaia also has a browser extension wallet called [Kaia Wallet](../tools/wallets/kaia-wallet.md), so it basically provides the same features as MetaMask, except for Remix. +> **注**：MetaMaskは主にイーサリアム用のウォレットとして使用されていますが、アドレス構造が同一であるためカイアとも互換性があります。 Kaiaには[Kaia Wallet](../tools/wallets/kaia-wallet.md)というブラウザ拡張ウォレットもあり、Remixを除けば基本的にMetaMaskと同じ機能を提供している。 -## Step 1. Install MetaMask +## ステップ1. Install MetaMask -* We will be using Chrome browser in this example. ([**Install Chrome**](https://www.google.com/intl/en_us/chrome/)) -* Add [**MetaMask Extension**](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn?hl=en) to Chrome. +* この例ではChromeブラウザーを使用します。 ([**Install Chrome**](https://www.google.com/intl/en_us/chrome/)) +* Chromeに[**MetaMask Extension**](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn?hl=en)を追加する。 - > **Note:** You may need additional installations if you are using another browser. -* You can start MetaMask by clicking on the icon in the upper right-hand corner of your chrome browser. + > \*\*他のブラウザを使用している場合は、追加のインストールが必要な場合があります。 +* クロームブラウザの右上にあるアイコンをクリックすると、MetaMaskが起動します。 -## Step 2. Generate a MetaMask Wallet +## ステップ2. Generate a MetaMask Wallet ![Create a Wallet](/img/build/tutorials/new-to-metamask.png) -* Click on [Create a Wallet]. -* Set a password. -* You will be given a 12 word seed phrase; back it up somewhere secure. +* ウォレットの作成]をクリックします。 +* パスワードを設定する。 +* 12語のシードフレーズが与えられるので、それを安全な場所にバックアップしてください。 - > **Note:** You can only restore your wallet with the seed phrase. Sharing your seed phrase with others may result in losing all of your funds. Therefore, it is recommended that you either write it down manually or store it in an offline device. + > \*\*注：\*\*シードフレーズでのみウォレットを復元できます。 シード・フレーズを他人と共有すると、資金をすべて失う可能性があります。 そのため、手動で書き留めるか、オフライン機器に保存することをお勧めする。 ![Seed phrase and Wallet](/img/build/tutorials/metamask-secret-backup.png) -## Step 3. Connect to Kaia Network +## ステップ3. Connect to Kaia Network -### A. Quick Configuration +### A. クイック設定 - Use ChainList for a one-click configuration and follow the instructions. + ワンクリックで設定できるChainListを使い、指示に従ってください。 Use ChainList for a one-click configuration and follow the instructions. -### B. Manual Configuration +### B. マニュアル設定 -1. Click on the upper Networks tab, which is on Ethereum Mainnet as default, and select [Add network]. +1. デフォルトでEthereum Mainnetになっている上部の[Networks]タブをクリックし、[Add network]を選択します。 ![Add Network](/img/build/tutorials/mm-network-btn.png) -2. Enter the following Kaia network details in the **Add a network manually** page and click **Save** +2. **Add a network manually**ページに以下のKaiaネットワークの詳細を入力し、**Save**をクリックします。 - + ```jsx title="Network Name " - Kaia Mainnet + カイア・メインネット ``` ```jsx title="New RPC URL " @@ -73,7 +73,7 @@ import TabItem from '@theme/TabItem'; ``` - + ```jsx title="Network Name " Kairos Testnet ``` @@ -96,19 +96,19 @@ import TabItem from '@theme/TabItem'; -## Step 4. Send KAIA +## ステップ4. Send KAIA -**Note:** The following steps require KAIA. For this guide, we will be using Kairos Testnet. You can obtain Test KAIA in [**Kaia Faucet**](https://faucet.kaia.io). +\*\*注：\*\*以下のステップはKAIAが必要です。 このガイドでは、Kairos Testnetを使用します。 テストKAIAは[**Kaia Faucet**](https://faucet.kaia.io)で入手できる。 -* Click [Send] on the main page and enter the recipient address and the amount of KAIA. +* メインページの[送信]をクリックし、受取人の住所とKAIAの金額を入力します。 ![Send KAIA 1](/img/build/tutorials/kairos-metamask-send.png) -**NOTE:** Sending KAIA is a payment transaction, for which you need KAIA. +**注意：** KAIA の送信は、KAIA が必要な支払い取引です。 -* Since Kaia v1.9.0, a [dynamic gas fee mechanism](https://medium.com/klaytn/dynamic-gas-fee-pricing-mechanism-1dac83d2689) has replaced the existing fixed price policy. -* So you don't have to set the fixed gas fee manually. -* Check the amount to send and the transaction fee and click [Confirm] to complete the KAIA transfer, after which you will be redirected to the main page. -* Click [Activity] on the main page to confirm the transaction history. +* カイアv1.9.0以降、従来の固定価格ポリシーに代わって[ダイナミック・ガス料金メカニズム](https://medium.com/klaytn/dynamic-gas-fee-pricing-mechanism-1dac83d2689)が採用された。 +* そのため、固定ガス料金を手動で設定する必要はない。 +* 送金額と送金手数料を確認し、[Confirm]をクリックしてKAIA送金を完了させてください。 +* メインページの[Activity]をクリックし、取引履歴を確認します。 ![Send KAIA 2](/img/build/tutorials/kairos-metamask-send-ii.png) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-remix.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-remix.md index ebb519a6655e..41895ea6fbd8 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-remix.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/connecting-remix.md @@ -1,28 +1,28 @@ -# Connect Remix to Klaytn +# RemixをKaiaに接続する ![](/img/banners/kaia-remix.png) -## Overview +## 概要 -Remix is a browser-based IDE (Integrated Development Environment) for developing Solidity contracts. In this guide, you will learn how to: +Remixは、Solidityコントラクトを開発するためのブラウザベースのIDE（統合開発環境）です。 このガイドでは、その方法を学ぶことができる： -- Create and Upload a pre-built smart contract on Remix IDE. -- Compile the smart contract. -- Connect to Kaia Plugin for Remix IDE -- Set up deployment environment -- Import account -- Connect Kaia to Remix using Kaia Wallet -- Connect Kaia to Remix using MetaMask -- Deploy the smart contract. -- Verify the smart contract. +- Remix IDEで事前に構築されたスマートコントラクトを作成し、アップロードします。 +- スマート・コントラクトをコンパイルする。 +- Remix IDE用Kaiaプラグインに接続する +- デプロイ環境のセットアップ +- インポートアカウント +- カイア・ウォレットを使ってカイアとリミックスをつなぐ +- MetaMaskを使ってKaiaとRemixを接続 +- スマートコントラクトをデプロイする。 +- スマート・コントラクトを検証する。 -This will cover connecting Remix with Kaia. If you want to know more about how to use Remix, please refer to [Remix docs](https://remix-ide.readthedocs.io/en/latest/) or [Remix IDE](https://remix.ethereum.org/). +これはカイアとのリミックスをカバーするものだ。 Remixの使い方については、[Remix docs](https://remix-ide.readthedocs.io/en/latest/)または[Remix IDE](https://remix.ethereum.org/)を参照してください。 -## Creating a file on Remix +## Remixでファイルを作成する -To start building a smart contract, click on **New File** icon in the **contracts** folder in the **File explorer** tab and name it `KaiaGreeter.sol` +スマート・コントラクトのビルドを開始するには、**File explorer**タブの**contracts**フォルダーにある**New File**アイコンをクリックし、`KaiaGreeter.sol`という名前を付ける。 -Next is to copy and paste the smart contract code provided below into the newly created KaiaGreeter.sol file. +次に、新しく作成したKaiaGreeter.solファイルに、以下に示すスマート・コントラクトのコードをコピー＆ペーストする。 ```sol // SPDX-License-Identifier: UNLICENSED @@ -46,77 +46,77 @@ contract KaiaGreeter { ![](/img/build/smart-contracts/remix-create-new-file.png) -## Compile smart contract +## スマート・コントラクトのコンパイル -To compile your contract, do the following: +契約書をまとめるには、以下のようにする： -- Go to the **Solidity Compiler** tab -- Select compiler version to 0.8.27 -- Turn on the 'Auto compile' option. -- Cliick on the Compile KaiaGreeter.sol button to compile `KaiaGreeter.sol` contract. -- After successful compilation, it will show a green tick mark on the Compiler tab button +- **Solidity Compiler** タブに移動します。 +- コンパイラのバージョンを0.8.27に選択 +- 自動コンパイル」オプションをオンにする。 +- CompileKaiaGreeter.solボタンをクリックして`KaiaGreeter.sol`コントラクトをコンパイルする。 +- コンパイルに成功すると、コンパイラ・タブのボタンに緑色のチェックマークが表示されます。 ![](/img/build/smart-contracts/remix-compile-contract.png) -## Connect to Kaia Plugin on Remix IDE +## Remix IDEでKaiaプラグインに接続する -To connect to Kaia plugin on Remix IDE, you can either use this [Kaia Plugin for Remix](https://ide.kaia.io/) or follow this step: +RemixのIDE上でKaiaプラグインに接続するには、こちらの[Kaia Plugin for Remix](https://ide.kaia.io/)を使うか、以下のステップに従ってください： -- Navigate to the **Plugin manager** tab -- Insert Klaytn in the search field -- Activate the Klaytn plugin. If Klaytn tab appears, you are ready to interact with Kaia. +- **Plugin manager**タブに移動します。 +- 検索フィールドにKlaytnを入れる +- Klaytnプラグインを有効にします。 Klaytnタブが表示されたら、カイアと対話する準備はできている。 ![](/img/build/smart-contracts/remix-plugin-addon.png) -## Setting up deployment environment +## デプロイ環境の構築 -- Click on the Klaytn plugin. -- Select the appropriate [Environment]. -- You can select Kairos, Mainnet, Injected Provider - Kaia Wallet, Injected Provider - MetaMask - - [Kairos]: Connects to the Kairos network - - [Mainnet]: Connects to the Mainnet - - [Injected Provider - Kaia Wallet]: Connects to Kaia Wallet - - [Injected Provider - MetaMask ]: Connects to Metamask +- Klaytnプラグインをクリックします。 +- 適切な[環境]を選択します。 +- Kairos、Mainnet、Injected Provider - Kaia Wallet、Injected Provider - MetaMaskを選択できます。 + - [カイロス］カイロス・ネットワークに接続 + - [メインネット]：メインネットに接続する + - [インジェクション・プロバイダー - カイア・ウォレット]：カイア・ウォレットに接続 + - [注入プロバイダ - MetaMask ]：メタマスクに接続する ![](/img/build/smart-contracts/remix-deploy-env.png) -## Import account +## インポートアカウント -You can export private key or Keystore from any compatible wallet to use here. +互換性のあるウォレットから秘密鍵またはKeystoreをエクスポートして、ここで使用することができます。 -- Click plus button next to the ACCOUNT. -- Then put private key or keystore. -- You can also import keys for the feePayer. It only supports private key. +- アカウントの横にあるプラスボタンをクリックします。 +- 次に秘密鍵またはキーストアを置く。 +- feePayerのキーをインポートすることもできます。 秘密鍵にしか対応していない。 ![](/img/build/smart-contracts/remix-import-acc.png) -## Connecting Kaia to Remix using Kaia Wallet  +## カイアウォレットを使ってカイアとリミックスを接続する -- Select [Injected Provider - Kaia Wallet] on the Remix Environment menu. +- Remix環境]メニューから[インジェクションプロバイダー - Kaia Wallet]を選択します。 ![](/img/build/smart-contracts/remix-kw-connect.png) -- When you see the Kaia Wallet pop-up, click [Connect]. -- Once you are successfully connected to the Network, you will see the Chain ID and Account of the connected network. +- カイアウォレットのポップアップが表示されたら、[接続]をクリックします。 +- ネットワークに正常に接続されると、接続されたネットワークのチェーンIDとアカウントが表示されます。 -## Connecting Kaia - Remix using MetaMask  +## カイアをつなぐ - MetaMaskを使ったリミックス -- Connect Kaia with MetaMask by referring to the [Connecting to MetaMask](./connecting-metamask.mdx). -- Select [Injected Provider - MetaMask] on the Remix Environment menu. +- MetaMaskとの接続](./connecting-metamask.mdx)を参照して、KaiaとMetaMaskを接続してください。 +- Remix Environmentメニューの[Injected Provider - MetaMask]を選択する。 ![](/img/build/smart-contracts/remix-mm-connect.png) -- When you see the MetaMask pop-up, select the account by clicking it. -- Once you are successfully connected to the Network, you will see the Chain ID and Account of the connected network. +- MetaMaskのポップアップが表示されたら、アカウントをクリックして選択します。 +- ネットワークに正常に接続されると、接続されたネットワークのチェーンIDとアカウントが表示されます。 -## Deploying the smart contract +## スマートコントラクトの導入 -In this section, we will deploy the KaiaGreeter.sol contract using Kaia Wallet. Having compiled the contract in the Compile Section, follow the deployment process below: +このセクションでは、Kaia Walletを使ってKaiaGreeter.solコントラクトをデプロイします。 コンパイルセクションでコントラクトをコンパイルしたら、以下のデプロイプロセスに従ってください： -- Set your deployment ENVIRONMENT to Injected Provider - Kaikas Wallet. Make sure to confirm all the connection prompts to Remix. -- Select the contract you want to deploy in the CONTRACT field. -- Click on the Deploy button. This would generate a Kaia Wallet popup that requires transaction confirmation. Simply confirm the transaction! +- デプロイメント環境を「Injected Provider - Kaikas Wallet」に設定します。 Remixへのすべての接続プロンプトを確認してください。 +- CONTRACTフィールドで展開したい契約を選択します。 +- Deployボタンをクリックします。 この場合、Kaia Walletのポップアップが表示され、取引の確認が必要となります。 取引を確認するだけです！ ![](/img/build/smart-contracts/remix-deploy-contract.png) -- You can view the deployed contract on [Kaiascan](https://kairos.kaiascan.io/), and also test or debug it on Remix IDE. +- デプロイされたコントラクトは[Kaiascan](https://kairos.kaiascan.io/)で見ることができ、Remix IDEでテストやデバッグもできます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/fee-delegation-example.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/fee-delegation-example.md index 0d4fb1098112..21338d62d762 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/fee-delegation-example.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/fee-delegation-example.md @@ -1,31 +1,31 @@ -# Build Fee Delegation Example +# 建築費の委任例 -## Table of Contents +## 目次 -- [1. Introduction](#1-introduction) -- [2. How fee delegation works](#2-how-fee-delegation-works) - - 2.1 Transaction signing by the sender - - 2.2 Transaction signing by the fee payer -- [3. Simple server and client for fee delegation](#3-simple-server-and-client-for-fee-delegation) - - 3.1 Sender's client - - 3.2 Fee payer's server -- [4. Run example](#4-run-example) - - 4.1 Run `feepayer_server.js` - - 4.2 Run `sender_client.js` - - 4.3 Check `feepayer_server.js` - - 4.4 Klaytn scope +- [1. はじめに](#1-introduction) +- [2. 料金委譲の仕組み](#2-how-fee-delegation-works) + - 2.1 送信者によるトランザクション署名 + - 2.2 料金支払者による取引署名 +- [3. 料金委譲のためのシンプルなサーバーとクライアント](#3-simple-server-and-client-for-fee-delegation) + - 3.1 送り手のクライアント + - 3.2 料金支払者のサーバー +- [4. 実行例](#4-run-example) + - 4.1 `feepayer_server.js` を実行する + - 4.2 `sender_client.js` を実行する + - 4.3 `feepayer_server.js` のチェック + - 4.4 カイアのスコープ -## 1. Introduction +## 1. はじめに -This tutorial helps you to write a simple server-client example using caver-js SDK to illustrate how fee delegated value transfer transaction works in Klaytn. This tutorial and the example code is using the Baobab testnet. +このチュートリアルは、Caver-js SDKを使用して、Kaiaにおける料金委譲トランザクションがどのように機能するかを説明する、簡単なサーバ・クライアントの例を書くのに役立ちます。 This tutorial and the example code is using the Baobab testnet. -## 2. How fee delegation works +## 2. 料金委譲の仕組み -Let's skim through how fee delegation works. +料金委譲の仕組みをざっと説明しよう。 -### 2.1 Transaction signing by the sender +### 2.1 送信者によるトランザクション署名 -`Sender` always should sign the transaction before sending a transaction. +送信者\`はトランザクションを送信する前に常にトランザクションに署名すべきである。 To sign a transaction, use [signTransaction](../../references/sdk/caver-js-1.4.1/api/caver.klay.accounts.md#signtransaction) which signs a transaction with given private key. @@ -51,15 +51,15 @@ const toAddress = "TO_ADDRESS"; const senderRawTransaction = tx.getRLPEncoding(); ``` -If there are no errors, then `senderRawTransaction` will have a signed transaction which is signed by the `senderPrivateKey`. +エラーがなければ、 `senderRawTransaction` は `senderPrivateKey` で署名されたトランザクションを持つ。 -Now, you need to send the `senderRawTransaction` to the fee payer. There will be various ways to implement this. In this tutorial, we will provide you a simple server-client code as an example of sending a `senderRawTransaction` to the fee payer. +次に、 `senderRawTransaction` を料金支払者に送信する必要があります。 これを実施する方法はいろいろあるだろう。 このチュートリアルでは、`senderRawTransaction`を料金支払者に送信する例として、簡単なサーバークライアントコードを提供します。 -### 2.2 Transaction signing by the fee payer +### 2.2 料金支払者による取引署名 -When `fee payer` receives the `senderRawTransaction`, `fee payer` signs the `senderRawTransaction` again with their private key and sends the transaction to Klaytn. The below code snippet illustrates the process. `kaia.sendRawTransaction` method signs the transaction with the given account's private key before sending the transaction. Before running the code, please replace `"FEEPAYER_ADDRESS"` and `"PRIVATE_KEY"` with the actual values. +フィー支払者は `senderRawTransaction` を受け取ると、秘密鍵で `senderRawTransaction` に再度署名し、Kaia にトランザクションを送信する。 以下のコード・スニペットはそのプロセスを示している。 Before running the code, please replace `"FEEPAYER_ADDRESS"` and `"PRIVATE_KEY"` with the actual values. コードを実行する前に、`"FEEPAYER_ADDRESS"` と `"PRIVATE_KEY"` を実際の値に置き換えてください。 -Note that when the `fee payer` submits the transaction to Kaia on behalf of the `sender`, the `senderRawTransaction` type must be a `FEE_DELEGATED` type of transaction. In the below example, [sendTransaction(FEE_DELEGATED_VALUE_TRANSFER)](../../references/sdk/caver-js-1.4.1/api/caver.klay/transaction/sendtx-value-transfer.md#sendtransaction-fee_delegated_value_transfer) method is invoked, because the original `senderRawTransaction` generated by the sender was [TxTypeFeeDelegatedValueTransfer](../../learn/transactions/fee-delegation.md#txtypefeedelegatedvaluetransfer). +手数料の支払者`が`送金者`に代わってKaiaにトランザクションを提出する場合、`senderRawTransaction`タイプは`FEE_DELEGATED`タイプでなければならないことに注意すること。 以下の例では、[sendTransaction(FEE_DELEGATED_VALUE_TRANSFER)](../../references/sdk/caver-js-1.4.1/api/caver.kaia/transaction/sendtx-value-transfer.md#sendtransaction-fee_delegated_value_transfer) メソッドが呼び出されます。これは、送信者によって生成された元の `senderRawTransaction\` が [TxTypeFeeDelegatedValueTransfer](../../learn/transactions/fee-delegation.md#txtypefeedelegatedvaluetransfer) であったためです。 ``` const feePayerAddress = "FEEPAYER_ADDRESS"; @@ -85,13 +85,13 @@ const tx = caver.transaction.decode(senderRawTransaction); .on('error', console.error); // If an out-of-gas error, the second parameter is the receipt. ``` -## 3. Simple server and client for fee delegation +## 3. 料金委譲のためのシンプルなサーバーとクライアント -Let's write a simple server and client using above fee delegation code. +上記の料金委譲コードを使って、簡単なサーバーとクライアントを書いてみよう。 -### 3.1 Environment setup +### 3.1 環境設定 -We will use `npm` and [caver-js](../../references/sdk/caver-js-1.4.1/get-started-1.4.1.md) to setup environment for this example as below. +`npm`と[caver-js](../../references/sdk/caver-js-1.4.1/get-started-1.4.1.md)を使って、この例の環境を以下のようにセットアップする。 ``` $ mkdir example @@ -100,11 +100,11 @@ $ npm init $ npm install caver-js@latest ``` -### 3.1 Sender's client +### 3.1 送り手のクライアント -First, we are going to write a `sender_client.js` as below. +まず、以下のように `sender_client.js` を書く。 -In the example, please replace `"SENDER_ADDRESS"`, `"SENDER_PRIVATEKEY"` and `"TO_ADDRESS"` with the actual values. +例では、`"SENDER_ADDRESS"`、`"SENDER_PRIVATEKEY"`、`"TO_ADDRESS"` を実際の値に置き換えてください。 ```javascript import { Socket } from "net"; @@ -171,13 +171,13 @@ sendFeeDelegateTx(); ``` -The above code signs a fee delegated value transfer transaction with `senderPrivateKey` and sends the signed `senderRawTransaction` to the fee payer's server which is running on port `1337` on `127.0.0.1`, i.e. localhost. +上記のコードは `senderPrivateKey` で手数料の委任された価値移転トランザクションに署名し、署名された `senderRawTransaction` を `127.0.0.1` のポート `1337` で動作している手数料支払者のサーバ、すなわち localhost に送信する。 -### 3.2 Fee payer's server +### 3.2 料金支払者のサーバー -Now let's write the fee payer's server, `feepayer_server.js`, which signs received `senderRawTransaction` with `feePayerPrivateKey` and sends it to Baobab testnet. +それでは、受信した `senderRawTransaction` に `feePayerPrivateKey` で署名し、Kairos testnet に送信する料金支払者のサーバ `feepayer_server.js` を書いてみよう。 -In the below example, please replace `"FEEPAYER_ADDRESS"` and `"FEEPAYER_PRIVATEKEY"` with actual values. +以下の例では、`"FEEPAYER_ADDRESS"`と`"FEEPAYER_PRIVATEKEY"`を実際の値に置き換えてください。 ```javascript import { createServer } from "net"; @@ -239,45 +239,45 @@ console.log("Fee delegate service started ..."); ``` -The server listens on port `1337`. +サーバーはポート `1337` をリッスンする。 -When there is incoming `data`, it signs the `data` with `feePayerPrivateKey` and sends it to the Klaytn blockchain. It assumes that the `data` is `senderRawTransaction` from the `sender_client.js`. +受信した `data` がある場合、`feePayerPrivateKey` で `data` に署名し、Kaia ブロックチェーンに送信する。 `data` は `sender_client.js` の `senderRawTransaction` であると仮定します。 -## 4. Run example +## 4. 実行例 -Prepare two terminals, one for `sender_client.js` and another for `feepayer_server.js`. +`sender_client.js`と`feepayer_server.js`の2つのターミナルを用意する。 -### 4.1 Run `feepayer_server.js` +### 4.1 `feepayer_server.js` を実行する -Below the command will start the fee payer's server. +以下のコマンドは、料金支払者のサーバーを起動する。 ``` $ node feepayer_server.js Fee delegate service started ... ``` -The server starts and is now listening on port 1337. +サーバーが起動し、ポート1337でリッスンしている。 -### 4.2 Run `sender_client.js` +### 4.2 `sender_client.js` を実行する -Let's run `sender_client.js` to send a fee delegated transaction. +それでは、`sender_client.js` を実行して手数料の委任トランザクションを送信してみよう。 ``` $ node sender_client.js -Signed a fee delegated value transfer transaction. -Sending a signed transaction to fee delegated service. -Connected to fee delegated service -Received data from server: This is fee delegating service -Received data from server: Fee payer is 0x811CE345DB9D8aD17513Cc77d76a1ace9eC46F02 -Received data from server: Tx hash is 0x1e6a019bb9c6cf156a6046ca33f0c810fb9fb6fdcb6df32b2e34a1d50f7f8a9d -Received data from server: Sender Tx hash is 0x7263d2dc5b36abc754726b220b7ad243dd789934109c6874e539ada5c7e9f193 +料金委譲価値移転トランザクションに署名。 +署名されたトランザクションを手数料代行サービスに送信。 + +サーバーからデータを受信：こちらは手数料代行サービス +サーバからデータを受信：Fee payer is 0x811CE345DB9D8aD17513Cc77d76a1ace9eC46F02 +Received data from server：Tx hash is 0x1e6a019bb9c6cf156a6046ca33f0c810fb9fb6fdcb6df32b2e34a1d50f7f8a9d +サーバーからデータを受信した：送信者 Tx ハッシュは 0x7263d2dc5b36abc754726b220b7ad243dd789934109c6874e539ada5c7e9f193 です。 ``` -It will sign a transaction with the `sender` private key and send the signed transaction to the fee delegated service (i.e., fee payer's server). Then it will receive the response from the fee delegate service including the `Fee payer` address, `Tx hash`, and `Sender Tx hash`. `Tx hash` is hash of a transaction submitted to the Klaytn network, while `Sender Tx hash` is hash of a transaction without the fee payer's address and signature. For more details, please take a look at [SenderTxHash](../../learn/transactions/transactions.md#sendertxhash). +送信者」の秘密鍵でトランザクションに署名し、署名されたトランザクションを料金支払者 のサーバーに送信する。 そして、料金支払い者アドレス、Txハッシュ、送信者Txハッシュを含む料金デリゲートサービスからの応答を受け取る。 `Tx hash`はKaiaネットワークに提出されたトランザクションのハッシュであり、`Sender Tx hash`は手数料支払者のアドレスと署名のないトランザクションのハッシュである。 詳しくは[SenderTxHash](../../learn/transactions/transactions.md#sendertxhash)をご覧ください。 -### 4.3 Check `feepayer_server.js` +### 4.3 `feepayer_server.js` のチェック -On the server's console, you will see below outputs. It prints the transaction receipt from the Klaytn. +サーバーのコンソールには、以下のような出力が表示される。 カイアからの取引レシートを印刷する。 ``` $ node feepayer_server.js @@ -384,10 +384,10 @@ Transaction receipt: { } ``` -### 4.4 Klaytn scope +### 4.4 カイアスコープ -You can also find the above transaction on the [Kaiascope](https://kairos.kaiascope.com). +上記の取引は[Kaiascope](https://kairos.kaiascope.com)でもご覧いただけます。 -It shows that the transaction is `TxTypeFeeDelegatedValueTransfer` and `Fee payer` is `0x811CE345DB9D8aD17513Cc77d76a1ace9eC46F02` or `feepayerAddress` that you entered, while `From` is a different address which should be the `senderAddress` in above example. +トランザクションは `TxTypeFeeDelegatedValueTransfer` で、`Fee payer` は `0x811CE345DB9D8aD17513Cc77d76a1ace9eC46F02` または入力した `feepayerAddress` である。 -![Fee delegated Tx](/img/build/tutorials/fee-delegation-example-kaia.png) +![料金委任Tx](/img/build/tutorials/fee-delegation-example-kaia.png) diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/kaia-wallet-dapp-integration.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/kaia-wallet-dapp-integration.md index 9b752da4347b..9e0a950a8848 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/kaia-wallet-dapp-integration.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/kaia-wallet-dapp-integration.md @@ -1,117 +1,117 @@ -# Kaia Wallet DApp Integration +# カイア・ウォレットDAppの統合 -## Table of Contents +## 目次 -1. [UI Libraries](#1-ui-libraries) -2. [Utility Libraries](#2-utility-libraries) -3. [Providers](#3-providers) +1. [UIライブラリ](#1-ui-libraries) +2. [ユーティリティ・ライブラリ](#2-utility-libraries) +3. [プロバイダー](#3-providers) -## Introduction +## はじめに -[Kaia Wallet](https://docs.kaiawallet.io) is a non-custodial wallet, similar to [Metamask](https://metamask.io), with additional support for Kaia-specific [Transactions](https://docs.kaia.io/learn/transactions) & [Accounts](https://docs.kaia.io/learn/accounts). This article will guide you through integrating [Kaia Wallet](https://docs.kaiawallet.io) with a decentralized application (dApp), from High-level (abstract) to Low-level (fine-grained) implementations. +[カイアウォレット](https://docs.kaiawallet.io)は、[メタマスク](https://metamask.io)と同様の非保護ウォレットで、カイア固有の[取引](https://docs.kaia.io/learn/transactions)と[アカウント](https://docs.kaia.io/learn/accounts)を追加サポートしています。 この記事では、[Kaia Wallet](https://docs.kaiawallet.io)と分散型アプリケーション(dApp)の統合について、高レベル(抽象的)な実装から低レベル(きめ細かい)実装まで説明します。 -For the sake of this guide, we will be dividing Kaia Wallet dApp integration into three main categories: +このガイドでは、Kaia Wallet dAppの統合を3つの主要カテゴリーに分類します： -- UI Libraries -- Utility libraries -- Providers +- UIライブラリ +- ユーティリティ・ライブラリ +- プロバイダー :::note -The aforementioned libraries use `Providers` under the hood. +前述のライブラリーは、`Providers`をボンネットの中で使っている。 ::: -## 1. UI Libraries +## 1. UIライブラリ -Many dApps utilize frontend frameworks for state management & delivering reactive services. The recommended way to integrate Kaia Wallet with such dApps is to use a UI Library built on the same framework. +多くのdAppは、状態管理とリアクティブなサービスの提供のためにフロントエンド・フレームワークを利用している。 そのようなdAppsとカイアウォレットを統合する推奨される方法は、同じフレームワークで構築されたUIライブラリを使用することです。 -UI Libraries provide components for user interactions, like `ConnectWallet` component. They also save you the hassle of managing low-level states, like Multiple Accounts & Multiple Networks. You can look at the underlying [Utility Library](#2-utility-libraries) or [Provider](#3-providers) for complex or low-level interactions. +UI ライブラリは、`ConnectWallet` コンポーネントのように、ユーザーとのインタラクションのためのコンポーネントを提供します。 また、複数アカウントや複数ネットワークのような低レベルの状態を管理する手間も省けます。 複雑な、あるいは低レベルのインタラクションについては、基礎となる[ユーティリティ・ライブラリ](#2-utility-libraries)や[プロバイダ](#3-providers)を参照することができる。 -While most UI libraries have built-in support for Metamask, integrating Kaia Wallet is also easy since its [API](https://docs.kaia.io/references/json-rpc/kaia/account-created/) is built on [Metamask's](https://docs.metamask.io/wallet/reference/json-rpc-api). Even if a library doesn't natively support Kaia Wallet, extending it for Kaia Wallet integration is straightforward. For example, these are 2 popular libraries for [React](https://react.dev) or [Next.js](https://nextjs.org): +ほとんどのUIライブラリはMetamaskをビルトインでサポートしているが、Kaia Walletの[API](https://docs.kaia.io/references/json-rpc/kaia/account-created/)は[Metamaskの](https://docs.metamask.io/wallet/reference/json-rpc-api)をベースに構築されているので、統合も簡単だ。 ライブラリがKaia Walletをネイティブにサポートしていなくても、Kaia Wallet統合のために拡張するのは簡単です。 例えば、[React](https://react.dev)や[Next.js](https://nextjs.org)の2つの人気のあるライブラリです： - [Appkit](#1.1-appkit-example) - [Web3-Onboard](#1.2-web3-onboard-example) -### 1.1. Appkit example +### 1.1. Appkitの例 ![Appkit Hero Banner](https://docs.reown.com/assets/images/appkit-18fbf6d4ddb8756740540b7adad92494.png) -By [Reown](https://reown.com/), [Appkit](https://docs.reown.com/appkit/overview) offers the following **Features:** +[Reown](https://reown.com/), [Appkit](https://docs.reown.com/appkit/overview) では、以下の**機能を提供しています:**。 -- Buttons + Modals for Connect Wallet, Account information, & Network information -- Support for [Email Wallets](https://docs.reown.com/appkit/authentication/socials), [Coinbase](https://www.coinbase.com) accounts, & [EIP-4361](https://docs.reown.com/appkit/authentication/one-click-auth) +- ウォレット接続、アカウント情報、ネットワーク情報のボタンとモーダル +- [Eメールウォレット](https://docs.reown.com/appkit/authentication/socials)、[Coinbase](https://www.coinbase.com)アカウント、および[EIP-4361](https://docs.reown.com/appkit/authentication/one-click-auth)をサポートします。 -**Considerations:** +**考慮事項** -- Using [@reown/appkit](https://www.npmjs.com/package/@reown/appkit), you have an option to commit to either the frontend stack of [Wagmi](https://wagmi.sh) & [Tanstack Query](https://tanstack.com/query) or simply [Ethers](https://docs.ethers.org/v6/) -- Requires a `projectId` [signup w/ Reown](https://cloud.walletconnect.com/sign-in) +- [@reown/appkit](https://www.npmjs.com/package/@reown/appkit)を使って、[Wagmi](https://wagmi.sh)&[Tanstack Query](https://tanstack.com/query)のフロントエンドスタックか、単に[Ethers](https://docs.ethers.org/v6/)のどちらかにコミットするオプションがある。 +- `projectId`が必要 [Reownでサインアップ](https://cloud.walletconnect.com/sign-in) :::note -Example Code: [kaikas-web3modal](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/kaikas.md) +コード例[kaikas-web3modal](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/kaikas.md) ::: -### 1.2. Web3-Onboard example +### 1.2. Web3-Onboardの例 ![Web3-Onboard Graphic](https://onboard.blocknative.com/_app/immutable/assets/connect-modal.b7439c5e.svg) -By [Blocknative](https://www.blocknative.com), [Web3-Onboard](https://onboard.blocknative.com) offers the following **Features:** +[Blocknative](https://www.blocknative.com)による[Web3-Onboard](https://onboard.blocknative.com)は以下の**機能を提供します:**。 -- Configurable Onboard text -- Modals for Connect Wallet, Switch Account, & Switch Network -- [Notification Components](https://onboard.blocknative.com/docs/modules/core#customnotification) -- (Optional) Register API Key(s) to fetch & render real-time data +- 設定可能なオンボード・テキスト +- Connect Wallet、Switch Account、Switch Networkの各モダル +- [通知コンポーネント](https://onboard.blocknative.com/docs/modules/core#customnotification) +- (オプション) リアルタイムデータをフェッチ＆レンダリングするためのAPIキーを登録する。 -**Considerations:** +**考慮事項** -- You'll have to write your Buttons +- ボタンを書く必要がある :::note -Example Code: [kaikas-web3onboard-react](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/web3Onboard.md) +コード例[kaikas-web3onboard-react](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/web3Onboard.md) ::: -## 2. Utility Libraries +## 2. ユーティリティ・ライブラリ -Libraries like [kaia-sdk](#21-kaia-sdk) & [ethers.js](#22-ethersjs-example) abstract just enough to streamline blockchain interactions while still being able to call [Provider](#3-providers) APIs directly. +[kaia-sdk](#21-kaia-sdk)や[ethers.js](#22-ethersjs-example)のようなライブラリは、ブロックチェーンのやり取りを効率化するのに十分な抽象化を行い、なおかつ[Provider](#3-providers)のAPIを直接呼び出すことができる。 -Using Utility Libraries to connect an account or send native tokens (e.g., KLAY/ETH) will be no different, _in terms of syntax & lines of code_, from calling Providers directly. Where libraries mainly improve are in the following areas: +ユーティリティライブラリを使用してアカウントを接続したり、ネイティブトークン（KAIA/ETHなど）を送信したりすることは、構文やコード行数\*の点で、プロバイダを直接呼び出すのと変わりません。 図書館が主に改善するのは、以下の分野である： -- Smart Contract interactions - - These involve ABIs, encoding inputs, & decoding outputs. Without a library, the code for these can be verbose & error-prone. -- Error-handling - - string error codes/messages are mapped to error Classes with custom properties & methods. -- Documentation & Type-safety +- スマートコントラクトの相互作用 + - これらには、ABI、エンコード入力、デコード出力が含まれる。 ライブラリーがないと、これらのコードは冗長でエラーになりやすい。 +- エラー処理 + - 文字列エラーコード/メッセージは、カスタムプロパティとメソッドを持つエラークラスにマッピングされます。 +- ドキュメンテーションと型式安全性 ### 2.1. kaia-sdk -[kaia-sdk](https://github.com/kaiachain/kaia-sdk) is a set of drop-in extensions for other Utility Libraries, like [ethers.js](https://docs.ethers.io/v6) & [web3.js](https://web3js.org). It allows you to use your preferred library while exposing first-party support for [Kaia-specific methods](https://docs.kaia.io/references/json-rpc/kaia/account-created/): +[kaia-sdk](https://github.com/kaiachain/kaia-sdk)は、[ethers.js](https://docs.ethers.io/v6)や[web3.js](https://web3js.org)のような他のユーティリティ・ライブラリのドロップイン拡張のセットです。 これにより、[カイア固有のメソッド](https://docs.kaia.io/references/json-rpc/kaia/account-created/)のファーストパーティ・サポートを公開しながら、お好みのライブラリを使用することができます： -- Transaction, Account, & Account Key types -- Fee Delegation +- 取引、口座、口座キーの種類 +- 手数料の委任 :::note -Example Code: [kaikas-web3klaytn](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/kaikas.md) +コード例[kaikas-web3klaytn](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/kaikas.md) ::: -### 2.2. ethers.js example +### 2.2. ethers.jsの例 -[ethers.js](https://docs.ethers.io/v6) is the [most popular](https://npmtrends.com/web3klaytn-vs-ethers-vs-viem-vs-web3) JavaScript Utility Library for interacting with the blockchain. It aims to be: +[ethers.js](https://docs.ethers.io/v6)は、ブロックチェーンと対話するための[最も人気のある](https://npmtrends.com/web3klaytn-vs-ethers-vs-viem-vs-web3)JavaScriptユーティリティライブラリです。 それを目指している： -- Extensive: support for multiple wallet formats, languages, & functions -- Robust: comprehensive tests, documentation, & typing +- 広範囲：複数の財布フォーマット、言語、機能をサポート +- 堅牢：包括的なテスト、文書化、型付け :::note -Example Code: [kaikas-ethersjs](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/ethers-js.md) +コード例[kaikas-ethersjs](https://github.com/kaiachain/kaia-dapp-mono/blob/main/examples/3rd-integration-examples/ethers-js.md) ::: -## 3. Providers +## 3. プロバイダー -At the lowest level is the Provider, [`window.klaytn`](https://docs.kaiawallet.io/02_api_reference/01_klaytn_provider) (Kaia Wallet itself). You might prefer [Utility Libraries](#2-utility-libraries), but knowledge of Provider APIs helps debug & understand how dependent libraries work. Referring to [Kaia's JSON-RPC API][Kaia-API] is necessary for using Kaia-specific methods like [`kaia_getAccount`](https://docs.kaia.io/references/json-rpc/kaia/get-account/), [`kaia_sendTransactionAsFeePayer`](https://docs.kaia.io/references/json-rpc/kaia/send-transaction-as-fee-payer/), & more. +最も低いレベルでは、プロバイダーである[`window.klaytn`](https://docs.kaiawallet.io/02_api_reference/01_klaytn_provider)（カイア・ウォレットそのもの）があります。 ユーティリティ・ライブラリ](#2-utility-libraries)を好むかもしれないが、プロバイダAPIの知識は、デバッグや依存ライブラリの動作を理解するのに役立つ。 [`kaia_getAccount`](https://docs.kaia.io/references/json-rpc/kaia/get-account/)、[`kaia_sendTransactionAsFeePayer`](https://docs.kaia.io/references/json-rpc/kaia/send-transaction-as-fee-payer/)などのKaia固有のメソッドを使用するには、[Kaia's JSON-RPC API][Kaia-API]を参照する必要があります。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/migrating-ethereum-app-to-kaia.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/migrating-ethereum-app-to-kaia.mdx index b7430a811aaf..7dff69edc483 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/migrating-ethereum-app-to-kaia.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/migrating-ethereum-app-to-kaia.mdx @@ -1,6 +1,6 @@ --- id: migrating-ethereum-app-to-kaia -title: Migrate Ethereum App to Kaia +title: EthereumアプリをKaiaに移行する --- import Tabs from '@theme/Tabs'; @@ -8,39 +8,39 @@ import TabItem from '@theme/TabItem'; ## Table of Contents -* [1. Introduction](#1-introduction) -* [2. Prerequisites](#2-prerequisites) -* [3. Kaia has Ethereum compatibility](#2-kaia-has-ethereum-compatibility) -* [4. Migrate App](#4-migrate-app) +* [1. はじめに](#1-introduction) +* [2. 前提条件](#2-prerequisites) +* [3. カイアはイーサリアムと互換性がある](#2-kaia-has-ethereum-compatibility) +* [4. アプリの移行](#4-migrate-app) ## 1. Introduction -This tutorial is intended to give a guide on how to migrate an Ethereum App to Kaia. No previous Kaia experience is needed. We will focus only on the code modifications required to migrate an Ethereum App to Kaia. +このチュートリアルでは、EthereumアプリをKaiaに移行する方法を説明します。 カイアの経験は問わない。 ここでは、EthereumアプリをKaiaに移行するために必要なコード修正のみに焦点を当てます。 ## 2. Prerequisites -* Familiarity with developer tooling and standards that support EVM. -* Basic knowledge building a dApp. +* EVMをサポートする開発者ツールや標準に精通している。 +* dAppを構築する基本的な知識 ## 3. Kaia has Ethereum compatibility -Kaia runtime environment is compatible with Ethereum Virtual Machine and executes smart contracts written in Solidity. Kaia's RPC APIs and other client libraries maintain almost identical API specifications with Ethereum's whenever available. Therefore, it is fairly straightforward to migrate Ethereum Apps to Kaia. This helps developers easily move to a new blockchain platform. +Kaia実行環境はEthereum仮想マシンと互換性があり、Solidityで書かれたスマートコントラクトを実行する。 KaiaのRPC APIやその他のクライアント・ライブラリは、利用可能な限りEthereumとほぼ同じAPI仕様を維持している。 したがって、Ethereum AppsをKaiaに移行するのは非常に簡単です。 これは、開発者が新しいブロックチェーン・プラットフォームに簡単に移行するのに役立つ。 ## 4. Migrate App -Migrate your Ethereum App to Kaia following the steps below: +以下の手順でEthereumアプリをKaiaに移行します： -1. Configure your contract tooling and SDKs to target Kaia Network - Kairos Testnet: - * RPC Endpoint: `https://public-en-kairos.node.kaia.io` - * WebSocket Endpoint (Optional): `wss://public-en-kairos.node.kaia.io/ws` - * Chain ID: 1001 +1. 契約ツールおよびSDKをKaia Network - Kairos Testnetをターゲットに設定します： + * RPCエンドポイント: `https://public-en-kairos.node.kaia.io` + * WebSocketエンドポイント（オプション）：wss://public-en-kairos.node.kaia.io/ws\`。 + * チェーン ID: 1001 -2. Create an account using the [Kaia Wallet](https://www.kaiawallet.io/) and get some test funds from the [Faucet](https://faucet.kaia.io). +2. カイア・ウォレット](https://www.kaiawallet.io/)を使ってアカウントを作成し、[Faucet](https://faucet.kaia.io)からテスト資金を得る。 -3. Deploy your contract(s) +3. 契約を展開する - + ```js // using Hardhat, it will be enough to add the following networks to the "hardhat.config.js" configuration file networks: { @@ -61,20 +61,20 @@ Migrate your Ethereum App to Kaia following the steps below: ``` - + ```js - forge create --rpc-url --private-key + forge create --rpc-url --private-key ``` -4. Interact with contract using [Kaia SDK](https://github.com/kaiachain/kaia-sdk). Feel free to use any other toolkit like [viem](../../references/sdk/viem/viem.md) or [web3.py](../../references/sdk/web3py-ext/getting-started.md). +4. カイアSDK](https://github.com/kaiachain/kaia-sdk)を使用して契約と対話します。 viem](../../references/sdk/viem/viem.md)や[web3.py](../../references/sdk/web3py-ext/getting-started.md)のような他のツールキットも自由に使ってください。 - **A. Read blockchain data** + **A. ブロックチェーンのデータを読む** - **BlockNumber** + **ブロック番号** - By simply replacing the web3 library with Kaia’s RPC Endpoint, you can sync Kaia's BlockNumber in real-time instead of Ethereum's BlockNumber. + web3ライブラリをKaiaのRPCエンドポイントに置き換えるだけで、EthereumのBlockNumberの代わりにKaiaのBlockNumberをリアルタイムで同期することができます。 ```js const { JsonRpcProvider } = require("@kaiachain/ethers-ext/v6"); @@ -94,7 +94,7 @@ Migrate your Ethereum App to Kaia following the steps below: ``` - **Contract Data** + **契約データ** ```js const ethers = require("ethers"); @@ -136,7 +136,7 @@ Migrate your Ethereum App to Kaia following the steps below: main(); ``` - **B. Write to the blockchain** + **B. ブロックチェーンへの書き込み** ```js const ethers = require("ethers"); diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/scaffold-eth.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/scaffold-eth.md index aefcf610bf2e..b5845206df2f 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/scaffold-eth.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/scaffold-eth.md @@ -1,146 +1,146 @@ -# Build a dApp using Scaffold-ETH 2 +# Scaffold-ETH 2を使用してdAppを構築する ![](/img/banners/kaia-scaffold.png) -## Introduction +## はじめに -Scaffold-ETH 2 is an open-source toolkit for building decentralized applications (dApps) on Ethereum and other EVM-compatible blockchains, like Kaia. Developers can easily deploy a Solidity smart contract and launch a dApp with a React frontend thanks to Scaffold-ETH 2. +Scaffold-ETH 2は、EthereumやKaiaのような他のEVM互換ブロックチェーン上で分散型アプリケーション（dApps）を構築するためのオープンソースのツールキットです。 開発者はScaffold-ETH 2により、Solidityスマートコントラクトを簡単にデプロイし、ReactフロントエンドでdAppを起動することができます。 -The Scaffold-ETH 2 toolkit was built using Next.js, RainbowKit, Hardhat, Foundry, Wagmi, and TypeScript. Developers can easily create, test, and deploy smart contracts using Hardhat or Foundry, as well as build a React frontend using Next.js. +Scaffold-ETH 2ツールキットは、Next.js、RainbowKit、Hardhat、Foundry、Wagmi、TypeScriptを使って構築された。 開発者は、HardhatやFoundryを使ってスマート・コントラクトを簡単に作成、テスト、デプロイでき、Next.jsを使ってReactフロントエンドを構築することもできる。 -In this tutorial, you will learn how to deploy, run a contract and build a dApp on Kaia using Scaffold-ETH 2. +このチュートリアルでは、Scaffold-ETH 2を使用してKaia上でデプロイ、コントラクトの実行、dAppの構築を行う方法を学びます。 -## Prerequisites +## 前提条件 -To get started with in this guide, you will need: +このガイドを始めるには、以下のものが必要だ： -- [Node (>= v18.17)](https://nodejs.org/en/download/) -- Yarn ([v1](https://classic.yarnpkg.com/en/docs/install/) or [v2+](https://yarnpkg.com/getting-started/install)) -- Familiarity with Javascript and React basics such as hooks -- [Metamask Wallet](https://metamask.io/download/) -- Test KAIA from [Faucet](https://faucet.kaia.io) -- RPC Endpoint: you can obtain this from one of the supported [endpoint providers](https://docs.kaia.io/references/public-en/) +- [ノード (>= v18.17)](https://nodejs.org/en/download/) +- 糸（[v1](https://classic.yarnpkg.com/en/docs/install/)または[v2+](https://yarnpkg.com/getting-started/install)）。 +- フックなど、JavascriptとReactの基本に精通していること +- [メタマスク財布](https://metamask.io/download/) +- [Faucet](https://faucet.kaia.io)からKAIAをテストする。 +- RPCエンドポイント：サポートされている[エンドポイント・プロバイダー](https://docs.kaia.io/references/public-en/)のいずれかから取得できます。 -## Setting up development environment +## 開発環境の構築 -To install Scaffold-ETH 2, you have two options, either to install by cloning [Scaffold-ETH 2 repository](https://github.com/scaffold-eth/scaffold-eth-2) or by using `npx create-eth@latest`. +Scaffold-ETH 2をインストールするには、[Scaffold-ETH 2リポジトリ](https://github.com/scaffold-eth/scaffold-eth-2)をクローンしてインストールするか、`npx create-eth@latest`を使用してインストールするかの2つの方法があります。 -For the sake of this guide, we will use the npx method to bootstrap our Scaffold-ETH 2 project. +このガイドでは、Scaffold-ETH 2プロジェクトのブートストラップにはnpxメソッドを使用します。 -Bootstrap a Scaffold-ETH 2 project by running the command below: +以下のコマンドを実行して、Scaffold-ETH 2プロジェクトをブートストラップします： ```bash npx create-eth@latest ``` -You will be presented with a series of prompts: +一連のプロンプトが表示されます： -**Project Name**: Input your project name: Enter a name for your project, e.g., kaia-scaffold-example. +**プロジェクト名**：プロジェクト名の入力: プロジェクト名を入力してください。 -**Solidity Framework**; What solidity framework do you want to use?: Choose your preferred solidity framework (Hardhat, Foundry). For this guide, we will use the Hardhat framework. +**Solidity Framework**; どのSolidityフレームワークを使用しますか？：お好みのSolidityフレームワーク（Hardhat、Foundry）を選択してください。 このガイドでは、Hardhatフレームワークを使用する。 -**Install packages?**: Press Enter for yes (default option) or type n and press Enter for no -Once the setup is complete, navigate to the project directory. +**パッケージをインストールしますか？**：はい（デフォルトのオプション）の場合はEnterキーを、いいえの場合はnと入力してEnterキーを押します +セットアップが完了したら、プロジェクトディレクトリに移動します。 ```bash cd project-name -// e.g cd kaia_scaffold +// 例： cd kaia_scaffold ``` -![Scaffold-ETH setup](/img/build/tutorials/scaffold-1.png) +足場ETHセットアップ](/img/build/tutorials/scaffold-1.png) -## Highlight of the development process with Scaffold-ETH 2 +## Scaffold-ETH 2による開発プロセスのハイライト -The process for developing a project with Scaffold-ETH 2 can be outlined as follows: +Scaffold-ETH 2を使ったプロジェクト開発のプロセスは以下のようになります： -1. Update the network configurations in Hardhat for Kaia -2. Add your smart contracts to the **packages/hardhat/contracts** -3. Edit your deployment scripts in the **packages/hardhat/deploy** -4. Deploy your smart contracts to Kaia -5. Verify your smart contracts with hardhat verify plugin -6. Configure your frontend to target Kaia in the **packages/nextjs/scaffold.config.ts** file -7. Edit your frontend as needed in the **packages/nextjs/pages** directory +1. カイアのハードハットのネットワーク設定を更新する +2. スマートコントラクトを **packages/hardhat/contracts** に追加する。 +3. **packages/hardhat/deploy**にあるデプロイスクリプトを編集します。 +4. スマートコントラクトをKaiaにデプロイする +5. ハードハット検証プラグインでスマートコントラクトを検証する +6. **packages/nextjs/scaffold.config.ts**ファイルで、Kaiaをターゲットとするフロントエンドを設定します。 +7. **packages/nextjs/pages**ディレクトリで、必要に応じてフロントエンドを編集してください。 -For the sake of this guide, we’ll use the default sample contract and frontend available after Scaffold-ETH 2 installation. All that is required is to modify these components for Kaia. In that case, we’ll split the configurations into **Hardhat** and **Next.js** configurations. +このガイドでは、Scaffold-ETH 2のインストール後に利用できるデフォルトのサンプルコントラクトとフロントエンドを使用します。 必要なのは、これらのコンポーネントをカイア用に変更することだけだ。 その場合、コンフィギュレーションを**Hardhat**と**Next.js**に分割する。 -## Hardhat Configuration +## ハードハットの構成 -In this section, you'll modify the network configurations in the Hardhat configuration file to target Kaia under the **packages/hardhat** folder. +このセクションでは、**packages/hardhat**フォルダの下にあるKaiaをターゲットに、Hardhat設定ファイルのネットワーク設定を変更します。 -### Configure Hardhat for Kaia +### カイアのハードハットを設定する -To configure hardhat for Kaia, you need to create a .env file and also modify hardhat.config.ts to support Kaia. +Kaia用にhardhatを設定するには、.envファイルを作成し、Kaiaをサポートするようにhardhat.config.tsを修正する必要があります。 -**Step 1: Create .env** +**ステップ1：.envの作成** -To create .env file, copy and paste the code below in your terminal +.envファイルを作成するには、以下のコードをターミナルにコピー＆ペーストする。 ```bash touch packages/hardhat/.env ``` -You can refer to the **.env.example** file for the variables that are already used in the hardhat.config.js file. For Kaia, you'll only need to create one variable: **DEPLOYED_PRIVATE_KEY**. +hardhat.config.jsファイルですでに使用されている変数については、**.env.example**ファイルを参照できる。 カイアの場合、必要な変数は1つだけです：**DEPLOYED_PRIVATE_KEY**。 -**Step 2: Edit your .env file to include this variable:** +**ステップ2：.envファイルを編集して、この変数を追加する。** ```bash -DEPLOYER_PRIVATE_KEY=INSERT_PRIVATE_KEY +deployer_private_key=insert_private_key ``` -The private key stated in your **.env** file corresponds to the account that will deploy and interact with the smart contracts in your Hardhat project. +**.env**ファイルに記述された秘密鍵は、Hardhatプロジェクトでスマート・コントラクトをデプロイし、やり取りするアカウントに対応します。 -**Step 3: Modify hardhat.config.ts** +**ステップ3：hardhat.config.tsを修正する。** -The next thing we want to do is to configure **hardhat.config.ts** to support Kaia. +次にやりたいことは、**hardhat.config.ts**をカイアに対応するように設定することだ。 -Set the constant **defaultNetwork** to the network you are deploying the smart contract to. +定数 **defaultNetwork** に、スマート・コントラクトをデプロイするネットワークを設定する。 ```js kairos: { - chainId: 1001, - url: "https://responsive-green-emerald.kaia-kairos.quiknode.pro/", - accounts: [deployerPrivateKey], - }, + chainId：1001, + url："https://responsive-green-emerald.kaia-kairos.quiknode.pro/", + accounts：[deployerPrivateKey], +}、 ``` -Add the network configurations for Kaia under the networks configuration object +カイアのネットワーク設定をネットワーク設定オブジェクトの下に追加する。 ```js -network: "kairos", +ネットワーク"kairos"、 ``` -For more information on using Hardhat with Kaia, please check [Hardhat guide](https://docs.kaia.io/build/get-started/hardhat/) for more details. +Hardhatをカイアで使用する際の詳細については、[Hardhatガイド](https://docs.kaia.io/build/get-started/hardhat/)をご確認ください。 -### Deploy Contract to Kaia +### カイアに契約を展開 -After configuring Hardhat to support the Kaia network, the next step is to compile and deploy the sample contract. +KaiaネットワークをサポートするためにHardhatを設定した後、次のステップは、サンプル契約をコンパイルし、デプロイすることです。 -First, you can compile your contract by running: +まず、契約書をコンパイルする： ```bash -yarn compile +ヤーンコンパイル ``` -![Compile](/img/build/tutorials/scaffold-2.png) +コンパイル](/img/build/tutorials/scaffold-2.png) -Then, you can run the following command from the root directory of your project: +次に、プロジェクトのルート・ディレクトリーから以下のコマンドを実行する： ``` -yarn deploy +ヤーン・デプロイ ``` -![Deploy](/img/build/tutorials/scaffold-6.png) +デプロイ](/img/build/tutorials/scaffold-6.png) -Note: +注： -> If you did not set the defaultNetwork config in the hardhat.config.ts file, you can append --network INSERT_NETWORK to the command. For example, the following command would deploy a contract to Kaia. +> hardhat.config.tsファイルでdefaultNetworkコンフィグを設定していない場合は、コマンドに--network INSERT_NETWORKを追加することができる。 例えば、以下のコマンドはカイアに契約をデプロイする。 > yarn deploy --network kaia -### Verify Your Deployed Contract +### 派遣契約の確認 -To verify our already deployed contract, we'll use the hardhat verify plugin. All that is required is to add the following configuration to your **hardhat.config.ts** under the etherscan configuration object for Kairos Testnet. +すでにデプロイされたコントラクトを検証するために、hardhat verifyプラグインを使おう。 必要なのは、Kairos Testnet用のetherscan設定オブジェクトの下にある**hardhat.config.ts**に以下の設定を追加することだけです。 ```js etherscan: { @@ -160,59 +160,59 @@ To verify our already deployed contract, we'll use the hardhat verify plugin. Al }, ``` -Next is to copy and paste the following command in your terminal to verify the smart contract: +次に、スマート・コントラクトを検証するために、以下のコマンドをターミナルにコピー＆ペーストする： -Example +例 ```js -yarn hardhat-verify --network network_name contract_address "Constructor arg 1" +yarn hardhat-verify --network network_name contract_address "コンストラクタの引数1" ``` -Actual +実際 ```js yarn hardhat-verify --network kairos 0x7fc9656fc8c8ab433867e58b7c6afc19ec4275da "0x7fc9656fc8c8ab433867e58b7c6afc19ec4275da" ``` -As you can see above, to verify your contracts, you have to pass in the network name, contract address and constructor arguments (if any). After a short wait, the console will display the verification result and, if successful, the URL to the verified contract on Kaiascope will be provided. +上で見たように、コントラクトを検証するには、ネットワーク名、コントラクトのアドレス、コンストラクタの引数（もしあれば）を渡す必要がある。 しばらく待つと、コンソールに検証結果が表示され、成功した場合は、Kaiascope上の検証済みコントラクトへのURLが提供されます。 -![Verify](/img/build/tutorials/scaffold-verify.png) +検証](/img/build/tutorials/scaffold-verify.png) -![Verify on Kaiascope](/img/build/tutorials/scaffold-3.png) +カイアスコープで検証](/img/build/tutorials/scaffold-3.png) -For more information about verifying smart contracts on Kaia using the Hardhat Verify plugin, please refer to the H[ardhat-Verify-Plugins guide](https://docs.kaia.io/build/smart-contracts/verify/hardhat/). +Hardhat Verifyプラグインを使用したKaia上でのスマートコントラクトの検証の詳細については、H[ardhat-Verify-Pluginsガイド](https://docs.kaia.io/build/smart-contracts/verify/hardhat/)を参照してください。 -## Next.js Configuration +## Next.jsの設定 -In this section, you'll modify the Next.js configuration to target Kairos Testnet (where the smart contract was deployed to) under the **packages/nextjs** folder. In this folder, we intend to modify the **targetNetwork** array in the scaffoldConfig object in **scaffold.config.ts** file. +このセクションでは、**packages/nextjs**フォルダの下にあるKairos Testnet（スマートコントラクトがデプロイされた場所）をターゲットとするように、Next.jsの設定を変更します。 このフォルダでは、**scaffold.config.ts**ファイルのscaffoldConfigオブジェクト内の**targetNetwork**配列を変更する予定です。 -### Modify the targetNetwork array +### targetNetwork配列を変更する ```js targetNetworks: [chains.klaytnBaobab], ``` -That's all required to configure Next.js! Next, is to launch the dApp in your localhost. +以上でNext.jsの設定は完了です！ 次に、ローカルホストでdAppを起動する。 -### Launch the dApp in your Localhost +### ローカルホストでdAppを起動する -After making all the necessary configurations, you can now launch the example dApp on your localhost. +必要な設定をすべて行ったら、ローカルホスト上でサンプルのdAppを起動できる。 -To do so, run: +そのためには、以下を実行する： ```bash -yarn start +ヤーンスタート ``` -![Run dApp](/img/build/tutorials/scaffold-4.png) +dAppの実行](/img/build/tutorials/scaffold-4.png) -You should now be able to access a React-based dApp frontend at http://localhost:3001/. Feel free to interact with the dApp by connecting your wallet or checking out the contract debugger page. +これで、http://localhost:3001/、ReactベースのdAppフロントエンドにアクセスできるようになるはずだ。 ウォレットに接続したり、コントラクトデバッガーのページをチェックしたりして、自由にdAppとやりとりしてください。 -![Scaffold dApp](/img/build/tutorials/scaffold-5.png) +スカフォールドdApp](/img/build/tutorials/scaffold-5.png) -## Conclusion +## 結論 -Congratulations! You have successfully used Scaffold-ETH 2 to deploy a contract and run a dApp on Kaia. Now that you understand the workings of Scaffold-ETH 2, feel free to create and deploy your own smart contracts and modify the frontend to fit your dApp's needs! +おめでとう！ Scaffold-ETH 2を使用してコントラクトをデプロイし、Kaia上でdAppを実行することに成功しました。 Scaffold-ETH 2の仕組みを理解したところで、自由に独自のスマートコントラクトを作成してデプロイし、dAppのニーズに合わせてフロントエンドを変更してください！ -Visit [Scaffold-ETH 2 Docs](https://docs.scaffoldeth.io/) for more information and [Kaia Forum](https://devforum.kaia.io/) if you have any questions. +詳しくは[Scaffold-ETH 2 Docs](https://docs.scaffoldeth.io/)を、ご質問があれば[Kaia Forum](https://devforum.kaia.io/)をご覧ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/tutorials.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/tutorials.md index 49bb1c9d848b..e8ce07346545 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/tutorials.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/tutorials.md @@ -1,6 +1,6 @@ -# Tutorials +# チュートリアル -This chapter contains practical dApp examples with complete source code and explanations. +この章では、実用的なdAppの例を完全なソースコードと解説付きで紹介する。 ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/verifying-contracts.md b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/verifying-contracts.md index c79678429efe..5a97998e3162 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/verifying-contracts.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/build/tutorials/verifying-contracts.md @@ -1,34 +1,34 @@ --- -sidebar_label: Verify Contracts +sidebar_label: 契約の確認 --- -# How to verify Smart Contracts Using Block Explorers +# ブロックエクスプローラーを使ったスマートコントラクトの検証方法 -## Introduction +## はじめに -Usually, the deployer of a smart contract is the only party with access to the code that was actually deployed, and the public cannot read the source code of a contract until the deployer has verified it. However, this is where contract verification comes in as an important step in the smart-contract development cycle, as it helps improve the transparency (for users), convenience (for developers), and security of deployed contracts. +通常、スマート・コントラクトのデプロイ者は、実際にデプロイされたコードにアクセスできる唯一の当事者であり、デプロイ者が検証するまで、一般人はコントラクトのソースコードを読むことができない。 コントラクトの検証は、（ユーザーにとっての）透明性、（開発者にとっての）利便性、そしてデプロイされたコントラクトの安全性を向上させるのに役立つからだ。 -Having said that, once a smart contract is validated, block explorers like Kaiascope and Kaiascan also make it possible for the public to interact with the contract's public methods using the block explorer's user interface. This is in addition to the public having direct access to the verified contract source code. +とはいえ、スマート・コントラクトが検証されると、KaiascopeやKaiascanのようなブロック・エクスプローラーは、ブロック・エクスプローラーのユーザー・インターフェースを使用して、一般の人がコントラクトのパブリック・メソッドと対話することも可能にする。 これは、一般の人々が検証済みの契約ソースコードに直接アクセスできることに加えてのことである。 -In this guide, we'll take a look at how to use block explorers to verify deployed smart contracts on the Klaytn Network. +このガイドでは、ブロックエクスプローラーを使用してKaiaネットワーク上でデプロイされたスマートコントラクトを検証する方法を見ていきます。 -## Prerequisites +## 前提条件 -- [Remix IDE](https://ide.kaia.io/) and [Kaia Wallet](https://docs.kaiawallet.io/getting_started/quick_start#install-kaia-wallet) -- Enough test KAIA from [faucet](https://faucet.kaia.io) +- [Remix IDE](https://ide.kaia.io/) と [Kaia Wallet](https://docs.kaiawallet.io/getting_started/quick_start#install-kaia-wallet) +- [Faucet](https://faucet.kaia.io)から十分なテストKAIA -## Getting Started +## はじめに -In this guide, we will be going over verifying both single contracts and multi-part contracts on the block explorers that exist in the Klaytn ecosystem, viz.: +このガイドでは、Kaiaエコシステムに存在するブロックエクスプローラーで、シングルコントラクトとマルチパートコントラクトの検証について説明します： -- [Kaiascope](https://kaiascope.com/) -- [Kaiascan](https://www.kaiascan.io/) +- [カイアスコープ](https://kaiascope.com/) +- [カイアスカン](https://www.kaiascan.io/) -Without further ado, let's get started! +さっそく始めよう！ -## Deploying a single Contract +## 単一契約の展開 -To verify a smart contract, you need to deploy the contract first on the target network. Hence, for the sake of this guide, we will be deploying the contract to Klaytn Baobab Testnet. Also, in this tutorial, we will be deploying a simple counter contract named `Counter.sol` on Remix IDE. The code is shown below: +スマート・コントラクトを検証するには、まずターゲット・ネットワーク上にコントラクトをデプロイする必要がある。 したがって、このガイドでは、Kaia Kairos Testnetにコントラクトをデプロイすることにする。 また、このチュートリアルでは、Remix IDE上に`Counter.sol`というシンプルなカウンターのコントラクトをデプロイする。 コードを以下に示す： ```solidity // SPDX-License-Identifier: MIT @@ -52,35 +52,35 @@ contract Counter { :::note -You can check this page for a tutorial on deploying smart contracts using [libraries](../../references/sdk/sdk.md) on Klaytn Baobab Testnet. You may also use a developer tool such as [Hardhat](../get-started/hardhat.md), [Foundry](../smart-contracts/deploy/foundry.md), [Remix](../smart-contracts/deploy/deploy.md#remix-ide) or another tool if preferred, to deploy the smart contract to Klaytn Baobab Testnet. +Kaia Kairos Testnetの[ライブラリ](../../references/sdk/sdk.md)を使用したスマートコントラクトのデプロイに関するチュートリアルは、こちらのページをご覧ください。 スマートコントラクトをKaia Kairos Testnetにデプロイするには、[Hardhat](../get-started/hardhat.md)、[Foundry](../smart-contracts/deploy/foundry.md)、[Remix](../smart-contracts/deploy/deploy.md#remix-ide)などの開発者ツールを使用することもできます。 ::: -## Parameters for single contract verification +## 単一契約検証のパラメータ -Verifying a contract on the block explorers requires some parameters, and these must be considered while deploying the smart contract. The following are some details related to the contract's compiler and deployment in order to verify a contract successfully: +ブロック・エクスプローラーでコントラクトを検証するには、いくつかのパラメータが必要で、スマート・コントラクトをデプロイする際に考慮しなければならない。 以下は、コントラクトをうまく検証するための、コントラクトのコンパイラとデプロイメントに関する詳細である： Remix IDE : -- On Remix IDE, navigate to the **Solidity compiler tab**. +- Remix IDEで、**Solidityコンパイラタブ**に移動します。 - - Observe the **compiler version** used to compile and deploy the contract. - - Observe the **Open Source License Type** used in the contract. This means the SPDX license identifier used at the beginning of the Solidity source file. In the `Counter.sol` file we used `// SPDX-License-Identifier: MIT` - - Observe the **EVM version** used for deploying contracts. - - (Optional) If **optimization** is enabled during compilation, take note of the value of the optimization runs parameter + - 契約のコンパイルとデプロイに使用された**コンパイラのバージョン**を確認してください。 + - 契約で使用されている**オープンソースライセンスの種類**を確認してください。 これは、Solidity ソース ファイルの先頭で使用される SPDX ライセンス識別子を意味します。 `Counter.sol`ファイルでは、`// SPDX-License-Identifier：MIT` + - コントラクトのデプロイに使用される**EVMバージョン**を確認してください。 + - (オプション）コンパイル時に**最適化**が有効になっている場合、最適化実行パラメータの値に注意する。 ![](/img/build/tutorials/counter-veri-parameters.png) -- On Remix IDE, navigate to **Klaytn tab**. +- Remix IDEで**Kaiaタブ**に移動します。 - - (Optional) If the contract constructor method accepts arguments, take note of the [ABI-encoded form](https://docs.soliditylang.org/en/develop/abi-spec.html) of the constructor arguments - - Take note of the contract address of the smart contract on the **Deployed Contracts** tab after successful deployment. + - (オプション) コンストラクタのメソッドが引数を受け付ける場合は、コンストラクタの引数の [ABI エンコード形式](https://docs.soliditylang.org/en/develop/abi-spec.html) に注意してください。 + - デプロイに成功したら、**Deployed Contracts**タブでスマートコントラクトのコントラクトアドレスをメモしてください。 ![](/img/build/tutorials/counter-veri-parametersII.png) -## Deploying a multi-part contract +## マルチパート契約の展開 -It is important to note that deploying a multi-part contract involves the same steps as deploying a single contract. For the sake of this guide, we will be deploying a simple KIP7 airdrop contract named `airdropToken.sol`. The code is shown below: +マルチパートのコントラクトのデプロイメントには、単一のコントラクトのデプロイメントと同じ手順が必要であることに注意することが重要である。 このガイドでは、`airdropToken.sol`という名前のシンプルなKIP7のエアドロップ契約をデプロイする。 コードを以下に示す： ```solidity //SPDX-License-Identifier: MIT @@ -114,86 +114,86 @@ contract TokenAirdrop is KIP7, Ownable { } ``` -## Parameters for multi-part contract verification +## マルチパート契約検証のパラメータ -The parameters for verifying a multi-part contract are the same as those for a single contract. However, because they are made up of multiple dependent contracts, we need to pre-process all dependencies of the contract into a single solidity file. This preprocessing is usually referred to as smart contract flattening. +マルチパート契約を検証するためのパラメータは、単一契約の場合と同じである。 しかし、それらは複数の依存するコントラクトで構成されているため、コントラクトのすべての依存関係を単一のsolidityファイルに前処理する必要があります。 この前処理は通常、スマート・コントラクトのフラット化と呼ばれる。 -For this reason, we will have to flatten the contract so it can be verified using the new flattened Solidity file on the block explorer. +このため、コントラクトをフラット化し、ブロックエクスプローラーで新しいフラット化されたSolidityファイルを使用して検証できるようにする必要があります。 Remix IDE: -- On Remix IDE, navigate to the **File explorer tab**. +- Remix IDEで、**ファイルエクスプローラタブ**に移動します。 - - Select the newly created contract under the **contracts** folder - - Click or tap with two fingers to see all commands available on the contract. - - Select **flatten** + - **contracts**フォルダの下に新しく作成した契約を選択します。 + - 2本指でクリックまたはタップすると、契約で利用可能なすべてのコマンドが表示されます。 + - フラット化\*\*を選択 ![](/img/build/tutorials/airdropToken-flattened.png) - - Once code is flattened, you will see a new contract named `airdropTokens_flattened.sol`. + - コードがフラット化されると、`airdropTokens_flattened.sol`という新しいコントラクトが表示されます。 ![](/img/build/tutorials/airdropToken-flattened-file.png) :::note -There are different tools for flattening a multi-part smart contract into a single Solidity file, such as [Hardhat Flattener](https://hardhat.org/hardhat-runner/docs/advanced/flattening). Kindly refer to the respective smart contract flattening tool's documentation for more detailed instructions on its usage. +マルチパートのスマートコントラクトを単一のSolidityファイルにフラット化するためのさまざまなツールがあります。たとえば、[Hardhat Flattener](https://hardhat.org/hardhat-runner/docs/advanced/flattening)があります。 スマート・コントラクト・フラットニング・ツールの詳細な使用方法については、それぞれのスマート・コントラクト・フラットニング・ツールのドキュメントを参照してください。 ::: -## Verifying the Contract +## 契約の確認 -Having obtained all of our verification parameters, we will go over the steps for verifying a single smart contract (Counter.sol) and a multi-part smart contract (airdropTokens.sol) on the block explorer in this section. +検証パラメータをすべて取得したので、このセクションでは、ブロック・エクスプローラ上で単一のスマート・コントラクト（Counter.sol）と複数パートのスマート・コントラクト（airdropTokens.sol）を検証する手順を説明します。 -### 1. Klaytnscope +### 1. Kaiascope -To verify a single contract and multi-part contracts on Klaytnscope, follow the steps below: +Kaiascopeで単一契約および複数パート契約を検証するには、以下の手順に従ってください： -#### 1.1 Verifying a single contract +#### 1.1 単一契約の検証 -1. Goto the search bar of [Kaiascope](https://kairos.kaiascope.com) and paste the deployed contract address. -2. Navigate to the **contract tab** on that page. -3. Click on the **Match Contract Source Code** link to submit contract code for verification. +1. [Kaiascope](https://kairos.kaiascope.com)の検索バーに、デプロイされた契約書のアドレスを貼り付ける。 +2. そのページの**契約タブ**に移動する。 +3. **Match Contract Source Code**リンクをクリックし、確認のために契約コードを提出する。 ![](/img/build/tutorials/counter-contract-tab.png) -4. On the contract verification page, make sure your account is connected to either Kaia Wallet or Metamask. For this guide, we will be using Kaia Wallet. -5. Fill in the contract address in the **contract address field**. Note: This field is usually filled with the contract address automatically. -6. Select the **compiler version** used for the `Counter.sol` example. -7. Select the **Open Source License Type** used for the `Counter.sol` example. For `Counter.sol` example, select the option, **MIT License (MIT)**. If there was none used, select **No License (None)**. -8. In the **Source Code field**, select **Source Text** and paste the source code for `Counter.sol` in the text-field. -9. Select **True** for **Optimization** if it was enabled during compilation, and fill in the number of runs under **Optimization Runs** to be **200**. -10. Select the **EVM version** for the contract. For `Counter.sol` example, select the option **Istanbul**. -11. Click on the CAPTCHA at the bottom and the **Sign and Submit** button to confirm and begin verification. +4. 契約確認ページで、アカウントがKaia WalletまたはMetamaskのいずれかに接続されていることを確認します。 このガイドでは、カイア・ウォレットを使用します。 +5. **契約住所欄**に契約住所を記入する。 注：このフィールドには通常、契約住所が自動的に入力されます。 +6. `Counter.sol`の例で使用した**コンパイラのバージョン**を選択する。 +7. `Counter.sol`の例で使用した**オープン・ソース・ライセンス・タイプ**を選択します。 Counter.solの例では、\*\*MIT License (MIT)\*\*を選択してください。 使用されていない場合は、\*\*ライセンスなし（None）\*\*を選択します。 +8. **Source Code**フィールドで、**Source Text**を選択し、テキストフィールドに`Counter.sol`のソースコードを貼り付けます。 +9. **最適化**がコンパイル時に有効になっている場合は**True**を選択し、**Optimization Runs**の実行回数を**200**になるように入力します。 +10. 契約の**EVMバージョン**を選択します。 `Counter.sol`の例では、**Istanbul**を選択する。 +11. 下部のCAPTCHAと**Sign and Submit**ボタンをクリックして確認し、認証を開始します。 ![](/img/build/tutorials/counter-verification-page.png) -12. After signing the verification request, you will get a verification status notification +12. 検証リクエストに署名した後、検証ステータスの通知が届きます。 ![](/img/build/tutorials/counter-success-popup.png) -13. Once verification is done, the result of the verification will be displayed in the browser, and a success result page with the contract address. Click on the contract address to view the **Contract Source Code**, **Contract ABI**, and **Bytecode**. +13. 検証が完了すると、検証結果がブラウザに表示され、契約先が記載された成功結果ページが表示される。 契約アドレスをクリックすると、**契約ソースコード**、**契約ABI**、**バイトコード**が表示されます。 ![](/img/build/tutorials/counter-success-popup-I.png) ![](/img/build/tutorials/counter-full-verification.png) -#### 1.2 Verifying multi-part contract +#### 1.2 複数パート契約の検証 -Verifying a multi-part contract on Klaytnscope is as straightforward as verifying a single contract, except that it requires some additional steps. In this section, we will be verifying the `airdropToken.sol` contract with the following additional steps: +Kaiascopeでの複数パート契約の検証は、いくつかの追加ステップが必要なことを除けば、単一契約の検証と同じくらい簡単です。 このセクションでは、`airdropToken.sol`コントラクトを以下のステップを追加して検証する： -- You can either Select **Source Text** under **Source Code** (step 3 of the Counter.sol example) or **Solidity File(s)** under the **Source Code** field. In the case of **Source Text**, copy the code in the `airdropToken_flattened.sol` and paste in the text field. If **Solidity File(s)**, you can download the `airdropToken_flattened.sol` file on Remix IDE and upload to the field. +- ソースコード**の下にある**ソーステキスト\*\*(Counter.solの例のステップ3)、または**ソースコード**フィールドの下にある\*\*ソリディティファイル(s)\*\*を選択することができます。 **Source Text** の場合、`airdropToken_flattened.sol` のコードをコピーしてテキストフィールドに貼り付けます。 もし、\*\*Solidity File(s)\*\*であれば、Remix IDE上で`airdropToken_flattened.sol`ファイルをダウンロードし、フィールドにアップロードしてください。 -a. Source Text +a. ソース・テキスト ![](/img/build/tutorials/airdrop-veri-field-I.png) -b. Solidity File(s) +b. ソリディティファイル ![](/img/build/tutorials/airdrop-veri-field-II.png) -After this, every other step remains the same as verifying a single contract. Having filled the verification parameter, click on the **Sign and Submit** button to confirm and begin verification. +この後、他のすべてのステップは、単一の契約を検証するのと同じである。 検証パラメータを入力したら、**Sign and Submit** ボタンをクリックして確認し、検証を開始します。 -Once verification is done, the result of the verification will be displayed in the browser, and a success result page with the contract address. Click on the contract address to view the **Contract Source Code**, **Contract ABI**, and **Bytecode**. +検証が完了すると、検証結果がブラウザに表示され、契約先が記載された成功結果ページが表示される。 契約アドレスをクリックすると、**契約ソースコード**、**契約ABI**、**バイトコード**が表示されます。 ![](/img/build/tutorials/airdrop-success-popup.png) @@ -201,43 +201,43 @@ Once verification is done, the result of the verification will be displayed in t ![](/img/build/tutorials/airdrop-full-verification.png) -### 2. Kaiascan +### 2. カイアスカン -To verify a single contract and multi-part contracts on Kaiascan, navigate to the [contract submission request page](https://kairos.kaiascan.io/contracts). However, make sure your account is connected to either Kaia Wallet or MetaMask and follow the steps below: +Kaiascanで単一契約および複数パート契約を確認するには、[契約書提出依頼ページ](https://kairos.kaiascan.io/contracts)に移動します。 ただし、アカウントがKaia WalletまたはMetaMaskのいずれかに接続されていることを確認し、以下の手順に従ってください： ![](/img/build/tutorials/klaytnfinder-con-sub-page.png) -#### 2.1 Verifying single contract +#### 2.1 単一契約の検証 -1. Observe the **Is this contract for a token** field? This field is needed when trying to verify a token contract with its official website URL, official email address, and token logo image. For the sake of this guide, select **No** as we are not verifying a commercial token contract. -2. Fill in the **contract address** for the deployed contract (Counter.sol) -3. Make sure to download `Counter.sol` from Remix IDE and upload in the **Source Code (Solidity File)** field -4. Select the **compiler version** used for the `Counter.sol` example -5. Select the **Open Source License Type** used for the `Counter.sol` example. For `Counter.sol` example, select the option, **MIT License (MIT)**. If there was none used, select **No License (None)** -6. Select the **EVM version** for the contract. For `Counter.sol` example, select the option **Istanbul**. -7. Select **True** for **Optimization** if it was enabled during compilation, and fill in the number of runs under **Optimization Runs** to be **200**. -8. (optional) To get the ABI-encoded constructor arguments for this field, navigate to [abi.hashex.org](http://abi.hashex.org) to get the encoded data following the image below: +1. **この契約はトークン**のためのものですか？ このフィールドは、トークンコントラクトの公式ウェブサイトのURL、公式メールアドレス、トークンロゴ画像を検証する際に必要となります。 このガイドでは、商業トークンコントラクトを検証しないため、**No**を選択します。 +2. 配置された契約（Counter.sol）の**契約アドレス**を記入してください。 +3. 必ずRemix IDEから`Counter.sol`をダウンロードし、\*\*Source Code (Solidity File)\*\*フィールドにアップロードしてください。 +4. `Counter.sol`の例で使用されている**コンパイラのバージョン**を選択してください。 +5. `Counter.sol`の例で使用した**オープン・ソース・ライセンス・タイプ**を選択します。 Counter.solの例では、\*\*MIT License (MIT)\*\*を選択してください。 使用されたものがない場合は、\*\*ライセンスなし（None）\*\*を選択する。 +6. 契約の**EVMバージョン**を選択します。 `Counter.sol`の例では、**Istanbul**を選択する。 +7. **最適化**がコンパイル時に有効になっている場合は**True**を選択し、**Optimization Runs**の実行回数を**200**になるように入力します。 +8. (オプション) このフィールドのABIエンコードされたコンストラクタ引数を取得するには、[abi.hashex.org](http://abi.hashex.org) にアクセスして、以下の画像に従ってエンコードされたデータを取得します： ![](/img/build/tutorials/abi-hashex.png) -9. Click on the **Sign and Submit** button to confirm and begin verification. +9. **Sign and Submit**ボタンをクリックして確認し、検証を開始します。 ![](/img/build/tutorials/counter-k-verification-page.png) -10. Once verification is done, you will get a **Submission Successful** message. Now you can paste the contract address in the explorer search bar to view the **Contract Source Code**, **Contract ABI**, **Creation Code** and **ABI-encoded Value**. +10. 認証が完了すると、**Submission Successful**というメッセージが表示されます。 これで、エクスプローラーの検索バーに契約書アドレスを貼り付けて、**契約書ソースコード**、**契約書ABI**、**作成コード**および**ABIエンコード値**を表示できる。 > ![](/img/build/tutorials/counter-k-full-verification.png) -### 2.2 Verifying multiple-part contract +### 2.2 複数パート契約の検証 -Verifying a multi-part contract on Kaiascan follows the same step as verifying a single contract. However, it is important to note we will be uploading the `airdropToken_flattened.sol` file in the **Source Code(Solidity File)** field. +Kaiascanで複数パートにまたがる契約を検証する場合は、単一の契約を検証する場合と同じ手順を踏みます。 ただし、\*\*Source Code(Solidity File)\*\*フィールドに`airdropToken_flattened.sol`ファイルをアップロードすることに注意してください。 ![](/img/build/tutorials/airdrop-k-verification-page.png) -After filling the verification parameters, click on the **Sign and Submit** button to confirm and begin verification. Once verification is done, you will get a **Submission Successful** message. Now you can paste the contract address in the explorer search bar to view the **Contract Source Code**, **Contract ABI**, and **Creation Code**. +検証パラメータを入力した後、**Sign and Submit** ボタンをクリックして確認し、検証を開始します。 認証が完了すると、**Submission Successful**というメッセージが表示されます。 エクスプローラーの検索バーにコントラクトアドレスを貼り付けると、**Contract Source Code**、**Contract ABI**、および**Creation Code**を表示できます。 ![](/img/build/tutorials/airdrop-k-full-verification.png) -## Conclusion +## 結論 -Congratulations on following this guide! In this tutorial, you learnt how to verify contracts (both single and multi-part) using Kaiascope and Kaiascan solely to enhance the transparency (for users), convenience (for developers), and security of deployed contracts. Visit [Kaia Docs](https://docs.klaytn.foundation/) for more information and [Kaia Forum](https://devforum.kaia.io/) if you have any questions. +このガイドに従ったことを祝福する！ このチュートリアルでは、KaiascopeとKaiascanのみを使用してコントラクト（シングル・パートとマルチ・パートの両方）を検証し、（ユーザーにとっての）透明性、（開発者にとっての）利便性、およびデプロイされたコントラクトの安全性を高める方法を学びました。 詳しくは[Kaia Docs](https://docs.klaytn.foundation/)、ご質問は[Kaia Forum](https://devforum.kaia.io/)をご覧ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-dlt-framework.md b/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-dlt-framework.md index 8f1979c4cf67..e1d42fa9593a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-dlt-framework.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-dlt-framework.md @@ -1,97 +1,97 @@ -# Kaia Chain DLT Framework +# カイアチェーンDLTフレームワーク -Our Distributed Ledger Technology (DLT) framework is designed to provide an efficient and reliable digital ledger system. The framework consists of the following key features: +当社の分散型台帳技術（DLT）フレームワークは、効率的で信頼性の高いデジタル台帳システムを提供するように設計されています。 このフレームワークは、次のような主要機能で構成されている： -## Layer Structure +## レイヤー構造 -- Our DLT framework operates in three layers of nodes: consensus nodes (CN), proxy nodes (PN), and endpoint nodes (EN). CN is managed by a Validator and is responsible for block creation. These blocks are verified by all the nodes within the network. -- A Core Cell (CC) is composed of a single Consensus Node (CN) and two Proxy Nodes (PNs). Consensus Nodes are participating in the block generation process, while Proxy Nodes provide the interface to the network. PNs transmit the transaction requests to the Consensus Nodes, and propagate the blocks down to the Endpoint Nodes. -- Endpoint Nodes (ENs) serve as endpoints for Kaia network handling RP API requests and processing data sent to and from service chains. +- 我々のDLTフレームワークは、コンセンサスノード（CN）、プロキシノード（PN）、エンドポイントノード（EN）の3層のノードで構成されている。 CNはバリデーターによって管理され、ブロックの作成を担当する。 これらのブロックは、ネットワーク内のすべてのノードによって検証される。 +- コアセル（CC）は、1つのコンセンサスノード（CN）と2つのプロキシノード（PN）で構成される。 コンセンサスノードはブロック生成プロセスに参加し、プロキシノードはネットワークとのインターフェースを提供する。 PNはトランザクション要求をコンセンサスノードに送信し、ブロックをエンドポイントノードに伝搬する。 +- エンドポイントノード（EN）は、RP APIリクエストを処理し、サービスチェーンとの間で送受信されるデータを処理する、Kaiaネットワークのエンドポイントとして機能します。 ![](/img/misc/kaia-nodes.jpg) -## Consensus algorithm +## コンセンサス・アルゴリズム -Blockchains use a “distributed ledger,” which consists of a connected network between individuals with several network participants to record and manage the transaction information. Each blockchain adopts a consensus algorithm that is most suitable for it, with the aim of efficient and smooth consensus on transaction validation and block generation among network participants. +ブロックチェーンは「分散型台帳」を使用し、複数のネットワーク参加者による個人間の接続されたネットワークで構成され、取引情報を記録・管理する。 各ブロックチェーンは、そのブロックチェーンに最適なコンセンサスアルゴリズムを採用し、ネットワーク参加者間での取引検証とブロック生成に関する効率的かつ円滑なコンセンサスを目指している。 -- Kaia uses an optimized version of Istanbul BFT, which implements PBFT (Practical Byzantine Fault Tolerance) with modifications to suit the characteristics of blockchain networks. +- カイアはイスタンブールBFTの最適化版を使用しており、これはブロックチェーン・ネットワークの特性に合わせて修正を加えたPBFT（Practical Byzantine Fault Tolerance）を実装している。 -The performance of Kaia is as follows: +カイアのパフォーマンスは以下の通り： -- Process 4,000 transactions/sec -- Instant transaction finality -- Creation time of 1 second/block +- 4,000トランザクション/秒の処理 +- 取引の即時確定 +- 作成時間1秒/ブロック -## Smart Contract +## スマート契約 -- Kaia supports a distributed virtual machine for executing smart contracts, which is designed to be fast and efficient, providing the best and swiftest development environment for dApp developers and projects. +- Kaiaはスマートコントラクトを実行するための分散型仮想マシンをサポートしており、高速かつ効率的に設計されているため、dApp開発者やプロジェクトに最適かつ迅速な開発環境を提供します。 -- The current version of Kaia Virtual Machine (KVM) is a derivative of the Ethereum Virtual Machine (EVM). It supports all Opcodes of the Ethereum Virtual Machine equally while providing additional precompiled contracts unique to the Kaia Virtual Machine. +- 現在のバージョンのカイア仮想マシン（KVM）は、イーサリアム仮想マシン（EVM）の派生版である。 Ethereum仮想マシンのすべてのOpcodeを同等にサポートし、Kaia仮想マシンに固有のプリコンパイルされたコントラクトを追加提供します。 -- Kaia supports Solidity and maintains interoperability with Ethereum development toolkits such as Remix, Hardhat, Truffle, and Foundry. A Smart Contract written with Solidity can be compiled using the existing Solidity compiler and can be run on Kaia without additional work. +- KaiaはSolidityをサポートし、Remix、Hardhat、Truffle、Foundryなどのイーサリアム開発ツールキットとの相互運用性を維持しています。 Solidityで記述されたスマートコントラクトは、既存のSolidityコンパイラを使用してコンパイルすることができ、追加作業なしでKaia上で実行することができます。 -## Security measures +## セキュリティ対策 -- We introduced a VRF(Verifiable Random Function) with the selection of the committee leader for the block generation consensus algorithm. VRF is a technology that randomly selects proposer nodes that generate blocks on each round, making it impossible to predict which nodes will be selected. +- 我々は、ブロック生成コンセンサスアルゴリズムの委員会リーダーの選択にVRF(Verifiable Random Function)を導入した。 VRFは、各ラウンドでブロックを生成する提案者ノードをランダムに選択する技術であり、どのノードが選択されるかを予測することは不可能である。 -- Kaia chain has a clear separation between the validator keys and rewards keys to protect them from stealing. Validator signatures need to be verified by all the committee members verifying the block creation. +- カイアチェーンでは、バリデータ・キーとリワード・キーを明確に分離し、盗難から保護している。 検証者の署名は、ブロック作成を検証する委員会メンバー全員によって検証される必要がある。 -## Interoperability +## 相互運用性 -- Kaia Blockchain is based on EVM so its compatible with Ethereum and all contracts developed in Solidity can run seamlessly with in Kaia Ecosystem. +- カイア・ブロックチェーンはEVMをベースにしているのでイーサリアムと互換性があり、Solidityで開発されたすべてのコントラクトはカイア・エコシステムでシームレスに実行できる。 -- Our DLT framework is designed based on EVM-SDK(Software Development Kit) technology, and is designed to interoperate with the same EVM-SDK based chains to deploy smart contracts without any code changes. +- 当社のDLTフレームワークは、EVM-SDK（ソフトウェア開発キット）技術に基づいて設計されており、同じEVM-SDKベースのチェーンと相互運用できるように設計されているため、コードを変更することなくスマートコントラクトを導入することができます。 -- It facilitates cross-platform transactions and smart contracts by enabling mutual asset movement, message exchange, and contract execution via inter. +- 相互のアセット移動、メッセージ交換、インターを介した契約実行を可能にすることで、クロスプラットフォーム取引とスマートコントラクトを促進する。 -## Tokenization +## トークン化 -- Kaia chain supports native coins as KAIA. +- カイアチェーンはKAIAとしてネイティブコインをサポートしている。 -- The framework provides the ability to issue and manage tokens, which can represent a variety of assets, including but not limited to cryptocurrencies, utility tokens, or asset-backed tokens, or NFTs. +- このフレームワークはトークンを発行・管理する機能を提供し、トークンは暗号通貨、ユーティリティ・トークン、資産担保型トークン（NFT）など、さまざまな資産を表すことができるが、これらに限定されるものではない。 -## Governance Protocol +## ガバナンス・プロトコル -- The on-chain governance of Kaia is designed to be fair and to ensure diverse opinions are shared. Voting entities can vote on all agenda items. Voting rights are calculated in proportion to the amount of staking. However, there is a cap on voting rights to prevent minority opinions from being ignored. Voters can delegate their staking amount to other voters. +- カイアのオン・チェーン・ガバナンスは、公正で多様な意見が共有されるように設計されている。 投票権を有する団体は、すべての議題について投票することができる。 議決権は賭け金額に応じて計算される。 ただし、少数意見が無視されるのを防ぐため、投票権には上限が設けられている。 投票者は、自分の賭け金額を他の投票者に委任することができる。 -- The submitted proposal is on-chain data that anyone can inquire about, and the description and information of the proposal, the result of the vote and the execution history of the proposal are recorded and transparently disclosed. +- 提出されたプロポーザルは、誰でも照会できるオンチェーンデータであり、プロポーザルの説明や情報、投票結果、実行履歴などが記録され、透明性をもって開示される。 -## Validators +## バリデーター -The consensus process consists of the following three stages: +コンセンサスのプロセスは、以下の3段階からなる： -- Step 1 – Election: A committee consisting of one proposer and several nodes is selected. This is a similar task to the leader election in a generally distributed system. The proposer and the committee are randomly selected through VRF since knowing them in advance can make them vulnerable to targeted DoS (denial of service). +- ステップ1 - 選挙：提案者1名とノード数名で構成される委員会が選出される。 これは、一般的な分散システムにおけるリーダー選出と同様の作業である。 提案者と委員会は、事前に知っていると標的型DoS（サービス拒否）に遭いやすくなるため、VRFによってランダムに選ばれる。 -- Step 2 - Block Generation: Elected proposers create a block and make a proposal to the committee. The block proposal made through the P2P network is sent to the committee. +- ステップ2 - ブロック作成：選出された提案者がブロックを作成し、委員会に提案する。 P2Pネットワークを通じて提案されたブロックは、委員会に送られる。 -- Step 3 - Block Verification: The committee verifies and signs the block proposed by the proposer. A block is complete when more than a quorum of signatures is collected. +- ステップ3 - ブロックの検証：委員会は、提案者によって提案されたブロックを検証し、署名する。 ブロックは、定足数以上の署名が集まった時点で完了となる。 -## Token Economy +## トークン・エコノミー -- The framework is automatically issued by the native token, KAIA, at the creation of each block, and the amount of KAIA issuance in each block is determined by the inflation ratio to the total supply. Kaia Blockchain provides incentives through newly minted KAIA and transaction fees. +- フレームワークは各ブロックの生成時にネイティブトークンであるKAIAによって自動的に発行され、各ブロックにおけるKAIAの発行量は総供給量に対するインフレ率によって決定される。 カイア・ブロックチェーンは、新たに鋳造されたKAIAと取引手数料を通じてインセンティブを提供する。 -- On the mainnet of Kaia Blockchain, a certain amount of KAIA is issued whenever a new block is created. Each time a new block is created, a certain amount of KAIA will be newly issued, and the target initial annual inflation rate (amount of KAIA newly issued per year / total KAIA token in the market) of Kaia Blockchain will be set at 5.2% . +- カイア・ブロックチェーンのメインネットでは、新しいブロックが作成されるたびに一定量のKAIAが発行される。 新しいブロックが作成されるたびに、一定量のKAIAが新たに発行され、カイアブロックチェーンの当初の目標年間インフレ率（1年間に新たに発行されるKAIAの量/市場のKAIAトークンの合計）は5.2％に設定されます。 -- Block Reward for each block will be distributed in prespecified percentages (that can be changed subject to on-chain governance voting). +- 各ブロックのブロック報酬は、あらかじめ指定されたパーセンテージで分配される（チェーン上のガバナンス投票によって変更可能）。 - 1. CCO and Community: 50% - 1. Of the 50%, 20% is Block Creator rewards - 2. Of the 50%, 80% is Staking rewards - 2. KEF (Kaia Ecosystem Fund): 25% - 3. KIF (Kaia Infrastructure Fund): 25% + 1. CCOとコミュニティ：50 + 1. 50％のうち、20％がブロック・クリエーターの報酬となる。 + 2. 50％のうち、80％がステーキング報酬である。 + 2. KEF（カイア・エコシステム・ファンド）：25% + 3. KIF（カイア・インフラストラクチャー・ファンド）：25% -## Auditability and transparency +## 監査可能性と透明性 -- All transactions provide an immutable and verifiable history of all state changes by recording the process from submission to execution in a block and transparently disclosing the entire past block history. +- すべてのトランザクションは、投稿から実行までのプロセスをブロック内に記録し、過去のブロック履歴全体を透過的に開示することで、すべての状態変更の不変かつ検証可能な履歴を提供する。 -- Kaia chain provides KaiaScope and Kaiascan to view all the transactions happening on the blockchain. +- カイアチェーンは、ブロックチェーン上で起きているすべての取引を閲覧するために、カイアスコープとカイアスキャンを提供している。 -- The data recorded in each block in the past can be viewed by anyone through the query function, thereby increasing transparency and confidence in the system. +- 各ブロックで過去に記録されたデータは、クエリー機能によって誰でも見ることができ、システムの透明性と信頼性を高める。 -- Kaia Chain provides voting platform “Square” to disclose all the expenses incurred and quarterly known transactions. +- カイアチェーンは、発生したすべての経費と四半期ごとに判明する取引を開示するために、議決権行使プラットフォーム「Square」を提供している。 -## Network Monitoring: +## ネットワーク監視： -- Kaia Blockchain adopts a multi-channel approach to deal with network congestion. By allocating separate propagation channels to transactions and blocks, the Kaia network can propagate newly created blocks in a timely manner even when the network faces severe congestion due to a large number of transactions. In turn, Kaia guarantees the dApps on the network to continue responding to end-user requests despite intermittent network traffic surges. +- カイア・ブロックチェーンは、ネットワークの混雑に対処するためにマルチチャネル・アプローチを採用している。 トランザクションとブロックに別々の伝搬チャネルを割り当てることで、Kaiaネットワークは、ネットワークが大量のトランザクションによる深刻な輻輳に直面しても、新しく作成されたブロックをタイムリーに伝搬することができる。 さらにカイアは、断続的なネットワークトラフィックの急増にもかかわらず、ネットワーク上のdAppsがエンドユーザーのリクエストに応答し続けることを保証する。 -- Kaia chain deploys the network monitoring for all the validators in the blockchain. +- カイアチェーンは、ブロックチェーン内のすべてのバリデータに対してネットワーク監視を展開する。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-white-paper.md b/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-white-paper.md index e7da9094791e..bfddb61cd301 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-white-paper.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/kaiatech/kaia-white-paper.md @@ -1,697 +1,697 @@ -# Kaia Blockchain White Paper v1.2 +# カイア ブロックチェーン ホワイトペーパー v1.2 -## Important Notice +## 重要なお知らせ -Project Kaia[^1] Digital Tokens (hereinafter referred to as “KAIA” with the ticker symbol KAIA) are not intended to constitute a regulated product such as securities, fiat tokens or e-money, accepted virtual assets or specified investments each as defined under the Financial Services and Markets Regulations 2015 of the Abu Dhabi Global Market (the “FSMR”), or its equivalent or any other regulated products in any jurisdiction. +プロジェクト・カイア[^1]デジタルトークン（以下、ティッカーシンボル「KAIA」で「KAIA」と呼ぶ）は、アブダビ・グローバル・マーケット（以下、「FSMR」と呼ぶ）の金融サービスおよび市場規制2015（Financial Services and Markets Regulations 2015）で定義される証券、フィアットトークン、電子マネー、受け入れ可能な仮想資産、特定投資などの規制対象商品、またはそれに相当する商品、またはその他の規制対象商品を構成するものではありません。 -Please note that you may not be able to recover any monies paid for KAIA in the event that the KAIA Token Economy fails to materialize or where the vision or objects of the Foundation fails. +KAIAトークンエコノミーが実現しなかった場合、または財団のビジョンや目的が達成できなかった場合、KAIAに支払われた金銭を回収できない可能性があることにご注意ください。 -This Whitepaper is meant to provide more information on the KAIA Token Economy and functions of KAIA, and does not constitute a prospectus or offer document of any sort. +このホワイトペーパーは、KAIAトークンエコノミーとKAIAの機能に関する詳細な情報を提供することを意図しており、いかなる種類の目論見書やオファー文書を構成するものではありません。 -This Whitepaper does not constitute or form part of any opinion or any advice to sell, or any recommendation or solicitation of any offer to purchase KAIA nor shall it or any part of it or the fact of its presentation form the basis of, or be relied upon in connection with, any contract or investment decision. +本ホワイトペーパーは、いかなる意見、売却のアドバイス、KAIAの購入の推奨や勧誘を構成するものでも、その一部を構成するものでもなく、また、契約や投資判断の基礎となるものでも、その発表の事実に依拠するものでもありません。 -No person is bound to enter into any contract or binding legal commitment in relation to the sale and purchase of KAIA and no digital tokens or other form of payment is to be accepted on the basis of this Whitepaper. +いかなる人も、KAIA の売買に関連していかなる契約または拘束力のある法的約束を締結する義務を負 わず、また、このホワイトペーパーに基づいていかなるデジタルトークンまたはその他の形態の支払いも受 け入れることはできません。 -Any agreement between the Foundation and you as a recipient or purchaser, and in relation to any airdrop, sale or purchase of KAIA is to be governed by a separate document setting out the terms and conditions (the “T&Cs”) of such agreement. In the event of any inconsistencies between the T&Cs and this Whitepaper, the T&Cs shall prevail. Your eligibility to receive, purchase or sell KAIA on any digital token trading platform or exchange is subject to your compliance with their respective terms and conditions. +財団と受取人または購入者であるあなたとの間の契約、およびKAIAの空輸、販売または購入に関連する契約は、当該契約の条件（以下「T&C」といいます）を定める別個の文書に準拠するものとします。 本利用規約と本ホワイトペーパーの間に矛盾がある場合は、本利用規約が優先されるものとする。 デジタル・トークン取引プラットフォームまたは取引所においてKAIAを受領、購入または売却する資格は、それぞれの利用規約を遵守することを条件とします。 -No regulatory authority has approved any of the information set out in this Whitepaper. No such action has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of this Whitepaper does not imply that the applicable laws, regulatory requirements or rules have -been complied with. +本ホワイトペーパーに記載された情報は、いかなる規制当局も承認していない。 いかなる法域の法律、規制要件、規則においても、そのような措置は取られておらず、また取る予定もない。 本ホワイトペーパーの発行、配布または普及は、適用される法律、規制要件または規則が +、遵守されていることを意味するものではない。 -This Whitepaper, any part thereof and any copy thereof must not be taken or transmitted to any country where distribution or dissemination of this Whitepaper is prohibited or restricted. +本ホワイトペーパーの配布または普及が禁止または制限されているいかなる国にも、本ホワイトペーパ ー、その一部、およびそのコピーを持ち出したり、送信したりしてはならない。 -No part of this Whitepaper is to be reproduced, distributed or disseminated without including this section and the section titled “IMPORTANT NOTES” at the back of this Whitepaper. +本ホワイトペーパーのいかなる部分も、本セクションおよび本ホワイトペーパーの巻末にある「重要な注意」と題されたセクションを含めない限り、複製、配布、流布することはできない。 -**PLEASE READ THE SECTION TITLED “IMPORTANT NOTES” AT THE BACK OF THIS WHITEPAPER VERY CAREFULLY.** +**このホワイトペーパーの巻末にある「重要な注意事項」をよくお読みください。** -**IF YOU ARE IN ANY DOUBT AS TO THE ACTION YOU SHOULD TAKE, YOU SHOULD CONSULT YOUR LEGAL, FINANCIAL, TAX OR OTHER PROFESSIONAL ADVISOR(S).** +**取るべき行動について疑問がある場合は、法律、財務、税務、その他の専門アドバイザーに相談してください。** -[^1]: Kaia is a temporary name for the integrated blockchain project of Klaytn and Finschia, and may be changed in the future. +[^1]: KaiaはKlaytnとFinschiaの統合ブロックチェーン・プロジェクトの仮の名称であり、将来変更される可能性がある。 -## Introduction +## はじめに -### Our Origin +### 私たちの原点 -The Finschia blockchain, based on the LINE Blockchain initiated by the global messaging company LINE in 2018, and the Klaytn blockchain, established in 2019 on the foundation of Kakao, South Korea's leading software company, have merged their blockchain and ecosystems under the shared goal of achieving mass adoption of blockchain technology to -create the Kaia Blockchain. +世界的なメッセージング企業であるLINEが2018年に開始したLINEブロックチェーンを基盤とするFinschiaブロックチェーンと、韓国の大手ソフトウェア企業であるKakaoの基盤の上に2019年に設立されたKlaytnブロックチェーンは、ブロックチェーン技術の大量導入を実現するという共通の目標の下、それぞれのブロックチェーンとエコシステムを統合し、 +、Kaiaブロックチェーンを創設した。 -Kaia Blockchain is a Layer 1 blockchain based on EVM (Ethereum Virtual Machine) and has been designed with scalability, convenience, and reliability as top priorities. Kaia Blockchain focuses on transformative changes that will empower not only technology and business but also individuals in the Web 3.0 era. Kaia Foundation[^2] and ecosystem participants aim for easier accessibility of blockchain technology and let more people participate in the Web 3.0 revolution. Kaia Blockchain will settle as a trusted stratum that connects people from different backgrounds all over the world. +カイア・ブロックチェーンは、EVM（イーサリアム仮想マシン）をベースとしたレイヤー1のブロックチェーンで、スケーラビリティ、利便性、信頼性を最優先に設計されている。 カイア・ブロックチェーンは、テクノロジーやビジネスだけでなく、Web3.0時代の個人にも力を与える変革に焦点を当てている。 カイア財団[^2]とエコシステムの参加者は、ブロックチェーン技術へのアクセスを容易にし、より多くの人々がウェブ3.0革命に参加できるようにすることを目指している。 カイア・ブロックチェーンは、世界中のさまざまな背景を持つ人々をつなぐ信頼できる地層として定着するだろう。 -To build the infrastructure for the collaborative Web 3.0 playground, Kaia Blockchain will combine powerful integrated community and infrastructure technologies to discover new opportunities and accelerate innovation. +コラボレーティブなウェブ3.0プレイグラウンドのインフラを構築するため、カイア・ブロックチェーンは強力な統合コミュニティとインフラ技術を組み合わせ、新たな機会を発見し、イノベーションを加速する。 -[^2]: It refers to the temporary foundation name of Project Kaia +[^2]: プロジェクト・カイアの仮の財団名を指す -### Mission +### ミッション -Our goal is to build a fairer and more open future by ensuring people greater economic opportunities and the right to participate through blockchain. +私たちの目標は、ブロックチェーンを通じて人々に大きな経済的機会と参加の権利を保障することで、より公平で開かれた未来を築くことです。 -### Vision +### ビジョン -The core vision of Kaia Blockchain is to integrate a broad user base, vast on-chain assets, and technology to help builders promptly implement and expand their ideas with successful results. As a platform, Kaia Blockchain provides the tools and environment required by the builders, providing them with the opportunity to introduce creative solutions to a wider public. They plan to create new value by leveraging on-chain assets and pursuing innovation that goes beyond technological limitations. The continued growth and success of the builder community is one of the core goals of Kaia Blockchain. For builders to turn their aspirations into reality, we will be helping builders turn their visions into reality, from the ideation stage through to implementation, market entry, and growth. +カイア・ブロックチェーンの核となるビジョンは、幅広いユーザーベース、膨大なオンチェーン資産、テクノロジーを統合し、ビルダーがアイデアを迅速に実行し、成功に導くよう支援することである。 プラットフォームとして、カイア・ブロックチェーンは構築者が必要とするツールと環境を提供し、より多くの人々に創造的なソリューションを紹介する機会を提供する。 オンチェーン資産を活用し、技術的な限界を超えたイノベーションを追求することで、新たな価値を創造する計画だ。 ビルダー・コミュニティの継続的な成長と成功は、カイア・ブロックチェーンの中核的な目標のひとつである。 私たちは、ビルダーがビジョンを現実のものとするために、アイデアの段階から、実行、市場参入、そして成長に至るまで、ビルダーを支援していきます。 -## Value Proposition +## バリュー・プロポジション -Kaia Blockchain aims to create Asia's \#1 blockchain through the integration of the two mainnets and lead the adoption of Web3, which was the common goal of the two blockchains. This vision can be achieved by helping builders create ideas, grow, and successfully build projects through a wide user base, abundant on-chain assets, and -technology leadership as below. Kaia Blockchain provides a robust infrastructure for Web3 projects of all sizes, creating an ideal environment for builders looking to bring innovative ideas to life. +カイア・ブロックチェーンは、2つのメインネットの統合を通じてアジアで1番のブロックチェーンを構築し、2つのブロックチェーンの共通の目標であったWeb3の導入をリードすることを目指しています。 このビジョンは、幅広いユーザーベース、豊富なオンチェーン資産、 +、以下のような技術リーダーシップを通じて、ビルダーがアイデアを生み出し、成長し、プロジェクトを成功させるのを支援することで達成できる。 カイア・ブロックチェーンは、あらゆる規模のWeb3プロジェクトに堅牢なインフラを提供し、革新的なアイデアを実現しようとするビルダーに理想的な環境を作り出します。 -### Wide User Base +### 幅広いユーザーベース -1. **Web2 User Accessibility**: One of the biggest problems facing Web3 projects is attracting Web2 users. Kaia Blockchain provides easy access to existing Web2 users through a messenger-integrated wallet through collaboration with Kakao with 50 million Korean users and LINE with 200 million users in Japan, Taiwan, Indonesia, and Thailand. +1. **Web2ユーザー・アクセシビリティ**：Web3プロジェクトが直面する最大の問題の一つは、Web2ユーザーを惹きつけることです。 カイア・ブロックチェーンは、韓国で5000万人のユーザーを持つカカオや、日本、台湾、インドネシア、タイで2億人のユーザーを持つLINEと連携し、メッセンジャーと統合されたウォレットを通じて、既存のWeb2ユーザーに簡単にアクセスできるようにする。 -2. **Web3 User Accessibility**: In addition to Web2 users, it helps attract Web3 users quickly and easily to the project by providing more than 1.2 million wallet active addresses and an interface connecting the users and the project. +2. **Web3ユーザーへのアクセシビリティ**：Web2ユーザーに加え、120万以上のウォレットアクティブアドレスと、ユーザーとプロジェクトをつなぐインターフェイスを提供することで、Web3ユーザーを素早く簡単にプロジェクトに引き込むことができます。 -3. **Community Building Support**: It helps users gather and build projects through joint marketing with Kaia Foundation and provides an environment with easy access and usage for users from various chains. +3. **コミュニティ形成支援**：カイア財団との共同マーケティングにより、ユーザーが集まり、プロジェクトを構築することを支援し、様々なチェーンのユーザーがアクセスしやすく、利用しやすい環境を提供する。 -### Abundant Liquidity Support +### 豊富な流動性サポート -1. **Real World Asset (RWA) Linkage**: Real world assets such as gold, ships, and real estate already exist on Kaia Blockchain. Beyond this, real world assets such as various fiat-backed stablecoins and bonds will be on-chained, allowing developers to utilize a wider range of assets. +1. **実世界資産（RWA）連携**：金、船舶、不動産などの現実世界の資産は、すでにカイアブロックチェーン上に存在しています。 これ以外にも、様々なフィアットに裏打ちされたステーブルコインや債券といった現実世界のアセットがオンチェーンされ、開発者はより幅広いアセットを利用できるようになる。 -2. **Large-Scale Ecosystem Fund (Kaia Ecosystem Fund):** A large-scale ecosystem fund can be created based on KAIA and support various sectors requiring liquidity such as Defi and Gamefi. +2. **大規模エコシステム・ファンド（Kaia Ecosystem Fund）：** KAIAをベースに大規模なエコシステム・ファンドを設立し、DefiやGamefiのような流動性を必要とする様々なセクターを支援することができる。 -3. **Chain Native Yield**: Built-in MEV (Maximal Extractable Value) extraction allows KAIA Stakers to automatically earn MEV profits on the chain. This results in an increase in the chain liquidity and simultaneously provides a method for burning tokens. +3. **チェーン・ネイティブ利回り**：MEV (Maximal Extractable Value)抽出機能により、KAIAステーカーは自動的にチェーン上でMEV利益を得ることができます。 その結果、チェーンの流動性が高まり、同時にトークンを燃やす方法が提供される。 -### Top-Level Core Technology and Development Convenience +### トップレベルのコア技術と開発の利便性 -1. **Top-Level Transaction Finality**: Provides higher TPS and decentralization while maintaining the 1-second transaction finality. +1. **トップレベルのトランザクション最終性**：1秒のトランザクション最終性を維持しながら、より高いTPSと分散化を提供。 -2. **Ethereum Compatibility:** EVM-based dApps can be onboarded without any modifications with the provision of 100% Ethereum compatibility. +2. **Ethereum互換性：** EVMベースのdAppは、100%のEthereum互換性を提供することで、何の修正も加えることなく搭載することができます。 -3. **Convenient Account Model:** The account model of Kaia Blockchain enables the assigning of various keys to accounts, which strengthens account security and improves user experience. +3. **便利なアカウントモデル：** カイア・ブロックチェーンのアカウントモデルは、アカウントに様々なキーを割り当てることを可能にし、アカウントのセキュリティを強化し、ユーザーエクスペリエンスを向上させます。 -4. **Permissionless and Decentralized Structure**: Kaia Blockchain is converting into a permissionless validator structure while also increasing the network’s decentralization. +4. **パーミッションレスと分散型構造**：カイア・ブロックチェーンは、ネットワークの非中央集権性を高めると同時に、パーミッションレスのバリデータ構造に転換している。 -## Token Economy +## トークン・エコノミー -### Introduction +### はじめに -Public blockchain platforms are maintained through a token model, which greatly influences the growth direction of the platform. Since blockchains generally do not have a central governing body, it is crucial to motivate the individuals who maintain and develop the blockchain to ensure its continued existence. However, it is unrealistic to expect participants to engage in blockchain security solely for altruistic motivations without seeking any financial gain. Therefore, an incentive system is necessary to motivate blockchain ecosystem participants to maintain and develop the network. +パブリック・ブロックチェーンのプラットフォームはトークン・モデルを通じて維持され、プラットフォームの成長方向に大きく影響する。 一般的にブロックチェーンには中央管理機関が存在しないため、ブロックチェーンの存続を保証するためには、ブロックチェーンを維持・開発する個人のモチベーションを高めることが極めて重要である。 しかし、参加者が金銭的な利益を求めず、利他的な動機だけでブロックチェーンのセキュリティに取り組むことを期待するのは非現実的だ。 そのため、ブロックチェーンエコシステムの参加者がネットワークを維持・発展させる動機付けとなるインセンティブシステムが必要となる。 -In blockchains, governance structures drive change. Blockchain platforms must change to keep pace with external developments as available technologies continue to expand and market needs change. Unlike general products developed and maintained by a single company or a central governing body, a public blockchain is not suitable for a single entity to make and implement unilateral decisions. For example, even if the main developers decide on a software update, the miners may not apply it. Therefore, a governance process is needed to collect the opinions of all participants in the ecosystem and make decisions based on the collected opinions in order for the blockchain network to implement timely changes. A stable governance structure must exist for the blockchain to adjust appropriately in response to external changes. +ブロックチェーンでは、ガバナンス構造が変化を促す。 ブロックチェーンプラットフォームは、利用可能な技術が拡大し続け、市場のニーズが変化するにつれて、外部の動きに合わせて変化していかなければならない。 一企業や中央管理機関によって開発・維持される一般的な製品とは異なり、パブリック・ブロックチェーンは単一の事業体が一方的に意思決定を行い、実行するのには適していない。 例えば、主要な開発者がソフトウェアのアップデートを決定しても、採掘者はそれを適用しないかもしれない。 したがって、ブロックチェーン・ネットワークがタイムリーな変更を実施するためには、エコシステム内のすべての参加者の意見を収集し、収集した意見に基づいて意思決定を行うガバナンス・プロセスが必要となる。 ブロックチェーンが外部の変化に応じて適切に調整されるためには、安定したガバナンス構造が存在しなければならない。 -This chapter explains the token model and governance system of Kaia Blockchain. Kaia Blockchain aims to help builders quickly implement, scale, and achieve successful results based on its large user base, vast on-chain assets, and technology. This document will go over the design principles used to create the current features of Kaia Blockchain and how these features may change. The information provided in this document will be verified through relevant data, and part of this content may be subject to change after sufficient verification and review. +この章では、カイア・ブロックチェーンのトークン・モデルとガバナンス・システムについて説明する。 カイア・ブロックチェーンは、その大規模なユーザー・ベース、膨大なオン・チェーン資産、技術に基づき、ビルダーが迅速に実装、拡張し、成果を達成できるよう支援することを目指している。 この文書では、カイア・ブロックチェーンの現在の機能を作成するために使用された設計原則と、これらの機能がどのように変更される可能性があるかについて説明します。 本書で提供する情報は、関連するデータによって検証されるものであり、十分な検証・検討の結果、内容の一部が変更される可能性がある。 -### Design Principles +### 設計原則 -Designing the token economy and governance structure of a blockchain platform is complex. First, token economy and governance structures are tested under controlled conditions that do not fully reflect reality. Therefore, it cannot be prepared for all variables. It is also worth noting that the blockchain industry is still in its infancy stage and we have yet to see a successful system that operates over the long term. Kaia Blockchain considered these environmental factors and defined internal principles that are not influenced by external influences rather than maintaining a single specific model. The detailed token economy and governance structure may flexibly evolve in line with the market conditions and regulations. However, the design principles will remain unchanged as a core value shared by all ecosystem participants. +ブロックチェーンプラットフォームのトークンエコノミーとガバナンス構造の設計は複雑だ。 第一に、トークンエコノミーとガバナンス構造は、現実を十分に反映しない管理された条件下でテストされる。 したがって、すべての変数に対応できるわけではない。 また、ブロックチェーン産業はまだ黎明期にあり、長期的に運用される成功したシステムをまだ見ていないことも注目に値する。 カイア・ブロックチェーンは、こうした環境要因を考慮し、単一の特定のモデルを維持するのではなく、外部の影響に左右されない内部原則を定義した。 詳細なトークンエコノミーとガバナンス構造は、市場の状況や規制に合わせて柔軟に進化する可能性がある。 しかし、エコシステム参加者全員が共有するコア・バリューとして、設計原則に変更はない。 -The core design principles of the token design of Kaia Blockchain are: +カイア・ブロックチェーンのトークン設計の核となる設計原則は以下の通りである： -- **Rewarding Ecosystem Contributors:** For a blockchain platform to be sustainable and provide great value to users, simply maintaining the network is not enough; the growth of the platform ecosystem is also very important. Therefore, Kaia Blockchain will identify the entities contributing to this growth and provide rewards and support commensurate with the contribution of each participant. This will result in not only contributors to block creation and verification but also service providers who have contributed to the growth of the platform ecosystem receiving reasonable compensation in proportion to their contribution, acting as an attractive incentive for potential external contributors. +- \*\*ブロックチェーンプラットフォームが持続可能で、ユーザーに大きな価値を提供するためには、単にネットワークを維持するだけでは不十分であり、プラットフォームのエコシステムの成長も非常に重要である。 したがって、カイア・ブロックチェーンは、この成長に貢献している主体を特定し、各参加者の貢献に見合った報酬とサポートを提供する。 これにより、ブロックの作成や検証への貢献者だけでなく、プラットフォーム・エコシステムの成長に貢献したサービス・プロバイダーも、その貢献度に応じた相応の報酬を受け取ることになり、潜在的な外部貢献者にとって魅力的なインセンティブとなる。 -- **Elastic Token Economy:** The token economy has numerous active participants with different interests and is greatly affected by various internal and external changes. Therefore, the token economy will be flexible to external variables based on consistent core principles rather than maintaining a single model. Based on these core principles, the token economy of Kaia Blockchain can respond quickly and flexibly to external changes. At the same time, it can support the ecosystem participants to operate stably and align the direction to promote overall growth. +- \*\*トークン・エコノミーは、さまざまな利害を持つ多数のアクティブな参加者を抱えており、内外のさまざまな変化に大きく影響される。 したがって、トークンエコノミーは、単一のモデルを維持するのではなく、一貫した基本原則に基づき、外部の変動要因に柔軟に対応する。 これらの基本原則に基づき、カイア・ブロックチェーンのトークンエコノミーは外部の変化に迅速かつ柔軟に対応することができる。 同時に、エコシステム参加者の安定した運営をサポートし、全体の成長を促進するための方向性を合わせることができる。 -- **Sustainable Growth:** Blockchain platforms must maintain continuous growth. In other words, it must retain the existing and new participants within the ecosystem based on a reasonable incentive model and a system that can flexibly respond to the needs and impacts of rapidly changing markets within and outside the ecosystem. In return, Kaia Blockchain will be able to achieve balanced and stable growth based solely on the contributions of ecosystem participants without any artificial value expansion. +- \*\*ブロックチェーン・プラットフォームは継続的な成長を維持しなければならない。 言い換えれば、合理的なインセンティブモデルと、エコシステム内外で急速に変化する市場のニーズや影響に柔軟に対応できるシステムに基づいて、エコシステム内の既存参加者と新規参加者を維持しなければならない。 その見返りとして、カイア・ブロックチェーンは、人為的な価値の拡大をすることなく、エコシステム参加者の貢献のみに基づいて、バランスの取れた安定した成長を達成することができる。 -- **Simplicity:** Kaia Blockchain will be explainable simply and clearly. This will allow for quick optimizations and fixes in the future. Its simplicity will allow everyone involved to easily understand the functionality. +- **シンプルさ：** カイア・ブロックチェーンはシンプルかつ明確に説明できる。 これにより、将来的に迅速な最適化と修正が可能になる。 シンプルなので、関係者全員が簡単に機能を理解できる。 -- **Experiment and Optimize with Data:** How high should inflation be? What types of rewards should be given for what actions? These questions are difficult to answer without testing and verification. Kaia Blockchain will transparently analyze data obtained and managed on the blockchain, optimize the platform by testing various hypotheses, and transparently share the results through technical reports. +- \*\*データによる実験と最適化：\*\*インフレ率はどの程度にすべきか？ どのような行動に対して、どのような報酬を与えるべきか？ このような疑問は、テストや検証なしに答えるのは難しい。 カイア・ブロックチェーンは、ブロックチェーン上で取得・管理されるデータを透過的に分析し、様々な仮説を検証することでプラットフォームを最適化し、技術レポートを通じて結果を透過的に共有する。 -### Kaia Blockchain Tokenomics +### カイア ブロックチェーン トーケノミクス #### KAIA -KAIA is the platform-native cryptocurrency of the Kaia Blockchain, used to enhance the security of the Kaia Blockchain through staking or to pay transaction fees. Transaction fees are incurred when deploying or executing smart contracts, or when transferring tokens. +KAIAはKaiaブロックチェーンのプラットフォームネイティブな暗号通貨で、ステーキングを通じてKaiaブロックチェーンのセキュリティを強化したり、取引手数料を支払ったりするために使用されます。 取引手数料は、スマートコントラクトの導入や実行、トークンの送金時に発生する。 -KAIA is an essential element and fuel for operating the Kaia Blockchain platform. The users’ KAIA is paid to the validators to execute tasks requested by clients of the platform. In other words, KAIA is an incentive that will ensure developers write high-quality application codes (wasteful codes cost more) and the network remains healthy (validators are compensated for the contributed resources). +KAIAは、カイア・ブロックチェーン・プラットフォームを運用するために不可欠な要素であり、燃料である。 利用者のKAIAはバリデーターに支払われ、プラットフォームのクライアントから要求されたタスクを実行する。 言い換えれば、KAIAは、開発者が高品質のアプリケーションコードを書くことを保証し（無駄なコードにはより多くのコストがかかる）、ネットワークが健全であり続けることを保証するインセンティブである（バリデータは貢献したリソースに対して補償される）。 -#### Kaia Blockchain’s Incentive Mechanism +#### カイア・ブロックチェーンのインセンティブ・メカニズム -The incentive mechanism of Kaia Blockchain seeks to achieve the following goals: +カイア・ブロックチェーンのインセンティブ・メカニズムは、以下の目標を達成しようとしている： -- Ability to maintain sufficient economic security and network over the long term. +- 長期にわたって十分な経済的安定とネットワークを維持する能力。 -- Support for entities promoting economic activity +- 経済活動を促進する事業体への支援 -In general, incentives in public blockchains are used to maintain the network and ensure economic security. Maintaining a blockchain requires someone to continuously store block data and process new transactions. Due to this, blockchains such as Bitcoin or Ethereum provide block rewards to miners processing block creation. Incentives are also closely related to economic security. Simply put, economic security is proportional to the cost required to carry out an attack on a blockchain. This cost typically becomes higher as the potential profit of the block creator increases during the block creation process. +一般に、パブリック・ブロックチェーンにおけるインセンティブは、ネットワークを維持し、経済的な安全性を確保するために用いられる。 ブロックチェーンを維持するには、誰かが継続的にブロックデータを保存し、新しいトランザクションを処理する必要がある。 このため、ビットコインやイーサリアムのようなブロックチェーンは、ブロック作成を処理するマイナーにブロック報酬を提供している。 インセンティブもまた、経済的安定と密接な関係がある。 簡単に言えば、経済的な安全性はブロックチェーンへの攻撃を実行するのに必要なコストに比例する。 このコストは通常、ブロック作成プロセスでブロック作成者の潜在的な利益が増加するにつれて高くなる。 -Incentives are necessary to ensure a high level of economic security and a well-maintained network. And for the system to operate stably, the value of cryptocurrency must be maintained or rise. If the value of cryptocurrency falls suddenly, the economic security and network stability may decline proportionally. +高い経済的安定性と整備されたネットワークを確保するためには、インセンティブが必要である。 そして、システムが安定的に稼働するためには、暗号通貨の価値が維持されるか上昇しなければならない。 暗号通貨の価値が突然下落すれば、それに比例して経済的な安全性やネットワークの安定性も低下する可能性がある。 -The stability or increase in value of KAIA largely depends on its utility. This utility comes from a large number of people using and burning KAIA, which occurs when high-quality service providers actively provide services on Kaia Blockchain. +KAIAの価値の安定や上昇は、その実用性に大きく左右される。 この効用は、多くの人々がKAIAを利用し、燃やすことによってもたらされるもので、高品質のサービス・プロバイダーがカイア・ブロックチェーン上で積極的にサービスを提供することによって発生する。 -#### Economically Sourced Incentives +#### 経済的インセンティブ -Kaia Blockchain provides incentives through the issuance of new KAIA and transaction fees. Additionally, to maintain the value of KAIA as a means of economic support, sustainable methods for distributing and burning KAIA exist. +カイア・ブロックチェーンは、新しいKAIAの発行と取引手数料を通じてインセンティブを提供する。 さらに、経済的支援手段としてのKAIAの価値を維持するために、KAIAを流通させ、燃やすための持続可能な方法が存在する。 -##### Minting +##### 鋳造 -On the Kaia Blockchain mainnet, a certain amount of KAIA is issued whenever a new block is created. Each time a new block is created, a certain amount of KAIA will be newly issued, and the target initial annual inflation rate (amount of KAIA newly issued per year / total KAIA token in the market) of Kaia Blockchain will be set at 5.2%[^3]. The number of newly issued KAIA per block at this point is not permanently set; it can be changed through governance voting. By default, the inflation rate of KAIA reflects the economic growth rate of Kaia Blockchain. Although the goal is a lower value, the exact value will be determined through the governance. In the mid to long term, the inflation rate and new issuance quantity per block can be automatically calculated and applied based on the inflation algorithm inherent in the chain. +カイア・ブロックチェーンのメインネットでは、新しいブロックが作成されるたびに一定量のKAIAが発行される。 新しいブロックが作成されるたびに、一定量のKAIAが新たに発行され、カイアブロックチェーンの目標年間インフレ率（年間新規発行KAIA量／市場のKAIAトークン総数）は5.2%[^3]に設定されます。 この時点のブロックごとの新規KAIA発行数は恒久的に決まっているわけではなく、ガバナンスの投票によって変更することができる。 デフォルトでは、KAIAのインフレ率はカイア・ブロックチェーンの経済成長率を反映している。 目標はより低い値だが、正確な値はガバナンスを通じて決定される。 中長期的には、ブロックごとのインフレ率と新規発行量は、チェーン固有のインフレアルゴリズムに基づいて自動的に計算され、適用される。 -[^3]: Specific figures are subject to change upon further review and governance approval. +[^3]: 具体的な数値は、さらなる検討とガバナンスの承認により変更される可能性がある。 -##### Transaction Fee +##### 取引手数料 -Kaia Blockchain has determined its transaction fee policy to maximize service orientation, user-centricity, and enterprise-friendliness while maintaining network stability. The transaction fee policy takes into account the following points pursued by Kaia Blockchain. +カイア・ブロックチェーンは、ネットワークの安定性を維持しつつ、サービス志向、ユーザー中心主義、企業フレンドリー性を最大化するために、取引手数料ポリシーを決定した。 取引手数料ポリシーは、カイアブロックチェーンが追求する以下の点を考慮している。 -- Improved User Experience - - We aim to minimize complicated or unnecessary procedures when users pay transaction fees. This will allow users not familiar with blockchain technology to easily use Kaia Blockchain. For example, tasks such as manually entering gas prices should be minimized. The volatility of the transaction fee should also be minimized so that users can use Kaia Blockchain comfortably. +- ユーザー・エクスペリエンスの向上 + - 当社は、利用者が取引手数料を支払う際の煩雑な手続きや不必要な手続きを最小限に抑えることを目指しています。 これにより、ブロックチェーン技術に詳しくないユーザーでも簡単にカイア・ブロックチェーンを利用できるようになる。 例えば、ガス料金を手入力するような作業は最小限にすべきである。 ユーザーが快適にカイア・ブロックチェーンを利用できるように、取引手数料の変動も最小限に抑えるべきである。 -- Improved Operational Processes for Service Providers - - Service providers can pay for the transaction fees on behalf of users through the unique account model in Kaia Blockchain. Therefore, business convenience for dApp service providers is also a major consideration in fee policy. - - The basic elements to reduce the burden on service providers are low transaction fees and low volatility fee policies. The low fee is to assist in the expansion of services using the fee delegation feature in the Kaia account model, while the low volatility is to help predict business costs due to the payment fee. +- サービスプロバイダーの業務プロセス改善 + - サービス・プロバイダーは、カイア・ブロックチェーンのユニークなアカウント・モデルを通じて、ユーザーに代わって取引手数料を支払うことができる。 したがって、dAppサービスプロバイダーにとってのビジネス上の利便性も、料金ポリシーにおける主要な考慮事項である。 + - サービス・プロバイダーの負担を軽減するための基本的な要素は、低取引手数料と低ボラティリティ手数料政策である。 手数料の低さは、カイアカウントモデルの手数料委譲機能を利用したサービス拡大を支援するためであり、ボラティリティの低さは、支払手数料によるビジネスコストの予測を支援するためである。 -- Protection against Network Attacks - - Blockchain data storage and computation incur costs. Without transaction fees, attackers may DDoS or spam attack the blockchain by sending meaningless transactions. To prevent meaningless transactions, a reasonable fee will be imposed on transactions. +- ネットワーク攻撃からの保護 + - ブロックチェーンのデータ保存と計算にはコストがかかる。 取引手数料がなければ、攻撃者は無意味なトランザクションを送信してブロックチェーンをDDoS攻撃したり、スパム攻撃したりするかもしれない。 無意味な取引を防ぐため、取引には相応の手数料が課される。 -Kaia Blockchain applies a dynamic gas fee model to the network to achieve the above goals. In the dynamic gas fee model of Kaia Blockchain, a low fee is applied in general cases where there are not many transactions on the network. However, in special situations such as a rapid increase in transactions on the network or a DDoS or spam attack, the gas fee increases. This results in a reduction of meaningless transactions. The dynamic gas fee model could change the gas fee per block unit dynamically depending on the transaction congestion within the network, but the range of change is predictable to some extent. Transactions entered into a block have transaction fees calculated with an identical block gas fee (baseFee), and only transactions with a gas fee greater than or equal to the block gas fee can be entered into the block. Block gas fees automatically increase or decrease depending on the gas usage of the previous block with the current maximum fluctuation set to 5%. A portion of the transaction fee used in each block is set to be automatically burned. Various parameters of the dynamic gas fee model can be changed via the governance function. +カイア・ブロックチェーンは、上記の目標を達成するため、ネットワークにダイナミックなガス料金モデルを適用している。 カイア・ブロックチェーンのダイナミック・ガス料金モデルでは、ネットワーク上の取引が多くない一般的なケースでは低料金が適用される。 ただし、ネットワーク上のトランザクションが急増したり、DDoS攻撃やスパム攻撃が発生したりするような特殊な状況下では、ガス料金は増額される。 その結果、無意味な取引を減らすことができる。 ダイナミック・ガス料金モデルは、ネットワーク内の取引の混雑状況に応じてブロック単位あたりのガス料金を動的に変更することができるが、その変更幅はある程度予測可能である。 ブロックに入力された取引は、同一のブロック・ガス・フィー（baseFee）で取引手数料が計算され、ブロック・ガス・フィー以上のガス・フィーを持つ取引のみがブロックに入力できる。 ブロックガス料金は、前のブロックのガス使用量に応じて自動的に増減し、現在の最大変動幅は5％に設定されている。 各ブロックで使用された取引手数料の一部は自動的に焼却されるように設定されている。 ダイナミック・ガス料金モデルの各種パラメーターは、ガバナンス機能によって変更することができる。 -The transaction fees for Kaia Blockchain are currently determined by applying a dynamic gas fee model. However, a new gas fee model or transaction fee policy may be required according to the environmental changes. If necessary, changes to the gas fee model or transaction fee policy of Kaia Blockchain will be made through the governance process. +カイア・ブロックチェーンの取引手数料は現在、動的ガス手数料モデルを適用して決定されている。 しかし、環境の変化に応じて、新たなガス料金モデルや取引料金ポリシーが必要になるかもしれない。 必要に応じて、カイアブロックチェーンのガス料金モデルまたは取引手数料ポリシーの変更は、ガバナンスプロセスを通じて行われます。 -##### Block Reward Distribution +##### ブロック報酬分配 -The block reward for each block is determined by the sum of the KAIA issued at the time of block creation and the transaction fee. This is distributed as follows. However, the specific ratio and category of the block reward distribution may be changed by governance. +各ブロックのブロック報酬は、ブロック作成時に発行されたKAIAと取引手数料の合計によって決定される。 これは以下のように分配される。 ただし、ブロック報奨金分配の具体的な比率とカテゴリーは、ガバナンスによって変更することができる。 -- Validators and Community: 50% - - Of the 50%, 20% is block proposer rewards - - Of the 50%, 80% is staking rewards -- KEF (Kaia Ecosystem Fund): 25% -- KIF (Kaia Infrastructure Fund): 25% +- 検証者とコミュニティ：50 + - 50％のうち、20％がブロック提案者への報酬である。 + - 50％のうち、80％は賭け金である。 +- KEF（カイア・エコシステム・ファンド）：25% +- KIF（カイア・インフラストラクチャー・ファンド）：25% -##### Burning +##### 燃焼 -The method for maintaining or enhancing the KAIA value is an essential element of any incentive structure based on KAIA. In Kaia Blockchain’s ecosystem growth stage, the additional issuance of the KAIA motivates the ecosystem members to participate. However, a method to control the circulation volume is necessary for it to operate as a long-term sustainable incentive. Kaia Blockchain 3-Layer Burn Model prevents excessive inflation. The 3-Layer Burn Model is an extensive concept that includes not only the inherent burning function of Kaia Blockchain but also the burning concept that can occur through relationships with ecosystem projects. This extensive burn model will effectively regulate circulation volume and provide stable value incentives to the network participants when the Kaia Blockchain ecosystem reaches maturity. The description of each Layer is as follows. +KAIAの価値を維持または向上させる方法は、KAIAに基づくインセンティブ構造にとって不可欠な要素である。 カイア・ブロックチェーンのエコシステムの成長段階において、KAIAの追加発行はエコシステムのメンバーの参加意欲を高める。 しかし、長期的に持続可能なインセンティブとして運用するためには、循環量をコントロールする方法が必要である。 カイア・ブロックチェーン3層バーンモデルは、過度の膨張を防ぐ。 3層燃焼モデルは、カイア・ブロックチェーン固有の燃焼機能だけでなく、エコシステム・プロジェクトとの関係を通じて起こりうる燃焼概念も含む広範な概念である。 この広範な燃焼モデルは、流通量を効果的に調整し、カイア・ブロックチェーン・エコシステムが成熟したときに、ネットワーク参加者に安定した価値インセンティブを提供する。 各レイヤーの説明は以下の通り。 -1. Transaction-Based Burning +1. トランザクションベースのバーニング -This is the default burning method provided by Kaia Blockchain. Users generate transactions to use the blockchain and a portion of the transaction fee is automatically burned. Since transaction-based burning can be interpreted as reduced profits of the node operators, the burning extent is adjusted through agreement and consensus among key network participants through on-chain governance. +これはカイア・ブロックチェーンが提供するデフォルトの書き込み方法である。 ユーザーはブロックチェーンを利用するためにトランザクションを生成し、取引手数料の一部が自動的に焼却される。 取引に基づく燃焼は、ノード運営者の利益を減少させると解釈できるため、燃焼の程度は、オンチェーンガバナンスを通じて主要なネットワーク参加者間の合意とコンセンサスを通じて調整される。 -2. MEV(Maximal Extractable Value) Burning +2. MEV（最大抽出値） 燃焼 -A validator may receive additional profits (e.g. maximal extractable value) by taking advantage of the fact that they can determine the transaction order during the block proposal process. This structure can escalate into issues of censorship or unfairness. As a result, Kaia Blockchain seeks to share the authority of the validator among all users through the implementation of technologies such as on-chain auctions. Part of the profit generated in this process will be burned due to it being generated through a special structural qualification called a validator. +バリデータは、ブロック提案プロセス中にトランザクションの順序を決定できるという事実を利用することで、追加的な利益（例えば、抽出可能な最大値）を得ることができる。 この構図は、検閲や不公平の問題に発展する可能性がある。 その結果、カイア・ブロックチェーンは、オンチェーン・オークションなどの技術を導入することで、バリデータの権限を全ユーザー間で共有しようとしている。 このプロセスで発生する利益の一部は、バリデーターと呼ばれる特殊な構造的資格を通じて発生するため、燃やされることになる。 -3. Business-Based Burning +3. 業務用バーニング -Business-based burning is not an inherent function of Kaia Blockchain. Rather it is implemented through the ecosystem services and business relationships. Ecosystem services can receive support from protocols such as Kaia Ecosystem Fund to initially accelerate growth. Additionally, the value of KAIA or the activation of Kaia Blockchain affects the activation of services considering services utilize blockchain functions. Kaia Blockchain encourages the ecosystem services to install the concept of burning KAIA within the service to ensure that the service and blockchain maintain the value of KAIA under the same goal. +ビジネスベースのバーニングは、カイア・ブロックチェーン固有の機能ではない。 むしろ、生態系サービスやビジネス関係を通じて実施される。 エコシステム・サービスは、カイア・エコシステム・ファンドのようなプロトコルから支援を受け、当初は成長を加速させることができる。 さらに、KAIAの価値やカイア・ブロックチェーンの活性化は、サービスがブロックチェーンの機能を利用することを考慮すると、サービスの活性化に影響する。 カイア・ブロックチェーンは、サービスとブロックチェーンが同じ目標の下でKAIAの価値を維持することを保証するために、KAIAを燃やすというコンセプトをサービス内に設置することをエコシステムサービスに奨励している。 -### Validator Incentives +### バリデーターのインセンティブ -Validators are operators in Kaia Blockchain who are responsible for block creation and verification based on the consensus algorithm. Validators are required to stake at least 5 million KAIA on the nodes they operate. In addition, validators participate in the on-chain vote of Kaia Blockchain and have the qualifications of GC (Governance Council), which makes key decisions in the ecosystem. In the future, the concepts of validator participating in block creation and GC participating in decision-making will be separated, so that anyone meeting certain conditions could participate in block creation and verification even if they are not a GC. Research and development of building this permissionless network is in progress. +バリデーターはカイア・ブロックチェーンのオペレーターで、コンセンサス・アルゴリズムに基づいてブロックの作成と検証を担当する。 バリデーターは、運営するノードに少なくとも500万KAIAを出資する必要がある。 さらに、バリデーターはカイア・ブロックチェーンのオンチェーン投票に参加し、エコシステムの重要な意思決定を行うGC（ガバナンス・カウンシル）の資格を持っている。 将来的には、バリデータがブロック作成に参加し、GCが意思決定に参加するという概念を分離し、GCでなくても一定の条件を満たせば誰でもブロック作成や検証に参加できるようにする。 このパーミッションレス・ネットワークを構築するための研究開発が進行中である。 -Two types of incentives are provided to encourage validators to operate nodes: block proposer rewards and staking rewards. +バリデータにノードの運用を促すために、ブロック提案者報酬とステーキング報酬の2種類のインセンティブが提供される。 -- Block proposer rewards are for the act of participating in block creation and verification. At the time of block creation, an identical amount of KAIA will be distributed to all validators activated on the network. 10% (20% of the 50% Validator and Community Rewards) of the total annual inflation issued will be allocated as block proposer rewards. However, the size of the reward in a specific block may vary depending on the number of validators active at a specific time. +- ブロック提案者の報酬は、ブロックの作成と検証に参加する行為に対するものです。 ブロック作成時に、ネットワーク上で有効化されたすべてのバリデーターに同量のKAIAが配布される。 年間発行インフレ総額の10％（50％の検証者報酬とコミュニティ報酬の20％）がブロック提案者報酬として割り当てられる。 しかし、特定のブロックにおける報酬の大きさは、特定の時間にアクティブなバリデーターの数によって変わる可能性がある。 -- Staking rewards are for staking KAIAs and contributing to the network stability and economic stability of Kaia Blockchain. The size of the reward is determined in proportion to the amount staked by a specific validator to the total amount of KAIA staked by all validators. However, the 5 million KAIA staked by each validator as an obligation is not reflected in determining the staking reward size. 40% of the total inflation will be allocated as staking rewards. The size of the rewards in a specific block may vary depending on the number of the total KAIA staked by the validators active at a specific time. +- ステーキング報酬は、KAIAをステーキングし、カイアブロックチェーンのネットワークの安定と経済の安定に貢献するためのものです。 報酬の大きさは、すべてのバリデーターが賭けたKAIAの総額に対して、特定のバリデーターが賭けた額に比例して決定される。 ただし、各バリデータが義務として賭けている500万KAIAは、賭け金の大きさを決定する際には反映されない。 インフレ総額の40％がステーキング報酬として配分される。 特定のブロックにおける報酬の大きさは、特定の時間にアクティブなバリデーターによって賭けられたKAIAの総数によって異なる場合があります。 -#### Kaia Blockchain Validator Reward Mechanism +#### カイア・ブロックチェーン検証者の報酬メカニズム -Every block will have a committee made up of randomly selected validators. Each committee will have one member to act as a proposer, and all other committee members will act as verifiers. When a block is successfully created and added to Kaia Blockchain, the proposer of that block will be rewarded with 10% (20% of the 50% Validator and Community Rewards) of the total annual inflation issued and additional transaction fees. With regard to transaction fees, if the total amount of transaction fees incurred in one block is less than the block reward, the fees will be burned. If the transaction fee exceeds the block reward, half of the exceeded amount will be burned and the remaining half will be rewarded to the block proposer. Staking rewards equivalent to 40% (80% of the 50% Validator and Community Rewards) of the total annual inflation issued are shared among the validators in proportion to their staking amount. As long as the Kaia Blockchain validators meet the minimum 5 million KAIA staking requirement, they are free to stake or unstake their KAIA. Staking information changed within the staking update cycle will have a final update in the last block of each cycle. Another cycle is required for the updated information to be reflected in the block incentive. For example, staking information added at block 80,000 will be last updated at block 86,400 and reflected in incentives starting at block 172,800. A one-week delay is required to withdraw the staked KAIA to prevent any immediate withdrawals by malicious members. +各ブロックには、無作為に選ばれたバリデーターで構成される委員会が設置される。 各委員会には提案者として1名の委員を置き、その他の委員は検証者として行動する。 ブロックが正常に作成され、カイアブロックチェーンに追加されると、そのブロックの提案者には、発行された年間インフレ総額の10％（50％のバリデータとコミュニティ報酬の20％）と追加取引手数料が報酬として支払われます。 取引手数料に関しては、1つのブロックで発生した取引手数料の合計額がブロック報酬を下回る場合、手数料は燃やされる。 取引手数料がブロック報酬を上回った場合、上回った金額の半分が焼却され、残りの半分がブロック提案者に報酬として支払われる。 年間発行インフレ総額の40%（50%のバリデータとコミュニティ報酬の80%）に相当するステーキング報酬が、ステーキング額に応じてバリデータ間で分配されます。 カイア・ブロックチェーンのバリデーターは、最低500万KAIAのステーキング要件を満たしている限り、KAIAをステーキングすることも、ステーキングを解除することも自由です。 ステーキング更新サイクル内で変更されたステーキング情報は、各サイクルの最後のブロックで最終更新される。 更新された情報がブロック・インセンティブに反映されるには、もう1サイクル必要である。 例えば、ブロック80,000で追加されたステーキング情報は、ブロック86,400で最終更新され、ブロック172,800からインセンティブに反映される。 悪意のある会員による即時の引き出しを防ぐため、賭けられたKAIAの引き出しには1週間の遅延が必要です。 -### Kaia Blockchain Fund +### カイア・ブロックチェーン・ファンド -#### Background +#### 背景 -The financial resources of the Kaia Blockchain ecosystem are reorganized and operated into the Kaia Ecosystem Fund (KEF) and Kaia Infrastructure Fund (KIF). Both KEF and KIF will be used to establish stable integrated governance and an active ecosystem and will be transparently executed according to the agreed-upon ratio. The usage plan of the ecosystem resources will be shared with the community in advance. Especially for KEF, individual expenditures will be executed with GC approval. This will allow all ecosystem participants to be proactively aware of the impact of the ecosystem resource execution. +カイア・ブロックチェーン・エコシステムの財源は、カイア・エコシステム・ファンド（KEF）とカイア・インフラストラクチャー・ファンド（KIF）に再編され運営されている。 KEFとKIFはともに、安定した統合ガバナンスと活発なエコシステムを確立するために使用され、合意された比率に従って透明性をもって実行される。 生態系資源の利用計画は、事前にコミュニティと共有される。 特にKEFについては、個々の支出はGCの承認を得て実行される。 これにより、すべての生態系参加者が、生態系資源実行の影響を積極的に認識できるようになる。 -#### Kaia Ecosystem Fund +#### カイア・エコシステム・ファンド -##### Definition +##### 定義 -Kaia Ecosystem Fund (KEF) is a financial resource used to ensure the sustainability of Kaia Blockchain mainnet by strengthening the basic ecosystem infrastructure, supporting developers, and returning profits through indirect investments back to the ecosystem. For this purpose, 25% of the total KAIA issued when creating a block will be distributed to KEF. KEF can only execute funds for agreed purposes with prior approval from the governance with all execution details being transparently disclosed. +カイア・エコシステム・ファンド（KEF）は、基本的なエコシステムのインフラを強化し、開発者を支援し、間接的な投資を通じて利益をエコシステムに還元することで、カイア・ブロックチェーン・メインネットの持続可能性を確保するために使用される財源です。 このため、ブロック作成時に発行されたKAIA総額の25％がKEFに分配される。 KEFは、合意された目的のために資金を執行する場合、すべての執行の詳細が透明性をもって開示された上で、ガバナンスの事前承認を得た場合にのみ、資金を執行することができる。 -##### Usage +##### 使用方法 -The uses of KEF are categorized as follows: +KEFの用途は以下のように分類される： -1. Service Contribution Reward (SCR): This reward is given to service developers or users operating on the integrated ecosystem, as compensation for directly or indirectly contributing to the enhancement of the ecosystem's value. +1. サービス貢献報酬（SCR）：この報酬は、エコシステムの価値向上に直接的または間接的に貢献した対価として、統合エコシステム上で活動するサービス開発者やユーザーに与えられる。 -2. Developer Community Development: This includes support for various hackathons, operation of development education programs, collaborative research with academia, and collaborations with various DAOs. +2. 開発者コミュニティ開発：各種ハッカソンへの支援、開発教育プログラムの運営、アカデミアとの共同研究、各種DAOとの連携などが含まれる。 -3. Ecosystem Services and Infrastructure Development: This involves the development of services with clear utilities, support for marketing, and securing essential infrastructure for the ecosystem. +3. 生態系サービスとインフラ整備：これには、明確なユーティリティを持つサービスの開発、マーケティングの支援、生態系に不可欠なインフラの確保が含まれる。 -4. KEF Indirect Investment: This involves medium to long-term investments carried out indirectly through delegation to professional crypto Venture Capitals. A portion of the profits generated from the recovery of investment amounts is either burned or returned to the Kaia Blockchain ecosystem. +4. KEF間接投資：これは、プロの暗号ベンチャーキャピタルへの委任を通じて間接的に行われる中長期的な投資を含む。 投資額の回収によって生じた利益の一部は、焼却されるか、カイア・ブロックチェーンのエコシステムに還元される。 -5. Governance Committee Budget: This budget is allocated for the operation of committees in specific sectors such as Gaming, DeFi, and Community. The committees aim to grow the Kaia Blockchain ecosystem in their respective sectors through expertise in investing, marketing, grants, and providing liquidity. +5. ガバナンス委員会予算：この予算は、ゲーミング、DeFi、コミュニティなど特定のセクターの委員会の運営に割り当てられる。 各委員会は、投資、マーケティング、助成金、流動性の提供などの専門知識を通じて、それぞれの分野でカイア・ブロックチェーンのエコシステムを成長させることを目指しています。 -6. Other ecosystem and community-building activities +6. その他の生態系およびコミュニティ構築活動 -##### Execution Method +##### 実行方法 -KEF operates under a system where the Governance Council (GC) reviews and approves the use of its funds. The budget executed through the foundation is managed through the following process: +KEFは、ガバナンス評議会（GC）が資金使途を検討・承認するシステムで運営されている。 財団を通じて執行される予算は、以下のプロセスで管理される： -1. Each quarter, necessary budgets by category of expenditure are reported to and approved by the GC. +1. 毎四半期、支出項目別に必要な予算がGCに報告され、承認される。 -2. Within the approved budget limits, specific expenditures are also approved individually by the GC. +2. 承認された予算の範囲内で、特定の支出もGCによって個別に承認される。 -3. Details of the expenditures are transparently disclosed after their use. +3. 支出の詳細は、使用後に透明性をもって開示される。 -Even if not through the foundation, new proposals for the use of KEF can be made via the GC, and these specific proposals will also require individual approval by the GC. Plans are in place to develop and enhance a structure that allows more ecosystem participants to efficiently propose and participate in the use of KEF. Additionally, for some categories requiring more specialized and rapid decision-making, separate governance committees may operate. +財団を通じてでなくとも、KEFの使用に関する新たな提案はGCを通じて行うことができ、これらの具体的な提案もGCによる個別の承認が必要となる。 より多くの生態系参加者がKEFの利用を効率的に提案し、参加できるような仕組みを開発・強化する計画がある。 さらに、より専門的で迅速な意思決定を必要とするカテゴリーについては、別のガバナンス委員会が運営されることもある。 -#### Kaia Infrastructure Fund +#### カイア・インフラストラクチャー・ファンド -##### Definition +##### 定義 -Kaia Infrastructure Fund (KIF) is a financial resource used for purposes such as R&D, ecosystem acceleration, and foundation operation. For this purpose, 25% of the total KAIA issued when creating a block will be distributed to KIF. +カイア・インフラストラクチャー・ファンド（KIF）は、研究開発、エコシステムの加速、財団運営などの目的に使用される財源である。 このため、ブロック作成時に発行されるKAIA総額の25％がKIFに分配される。 -KIF is executed by the foundation through an internal control system after a prior announcement of the budget plan for each detailed category with all execution details being transparently disclosed. +KIFは、詳細なカテゴリーごとに予算計画を事前に公表し、執行内容をすべて透明性をもって開示したうえで、財団が内部統制システムを通じて執行する。 -##### Usage +##### 使用方法 -The uses of KIF are categorized as follows: +KIFの用途は以下のように分類される： -1. Mainnet and Essential Infrastructure R&D: Advance research on the latest technologies related to mainnet and infrastructure, foundation-led service development, infrastructure establishment, etc. +1. メインネット・基幹インフラの研究開発：メインネット・基幹インフラに関する最新技術の研究開発、財団主導のサービス開発、インフラ構築などを推進。 -2. Ecosystem Acceleration: Token swap, financial support for small-scale Kaia Blockchain ecosystem partners, attraction of new GC, provision of market liquidity, etc. +2. エコシステムの加速：トークンの交換、小規模なカイアブロックチェーンエコシステムパートナーへの財政支援、新規GCの誘致、市場流動性の提供など。 -3. Operation of Kaia Foundation: Operating costs (various service costs such as development, accounting, legal affairs, as well as IT infrastructure operation costs, marketing costs, labor costs, etc.), financial management, fundraising, etc. +3. カイア財団の運営運営費（開発、経理、法務などの各種サービス費、ITインフラ運用費、マーケティング費、人件費など）、財務管理、資金調達など。 -##### Execution Method +##### 実行方法 -The foundation directly establishes a budget plan and executes the funds accordingly for KIF. To ensure transparent execution, the foundation discloses the budget plans and execution details in advance and afterward. +財団は直接、KIFのために予算計画を立て、それに従って資金を執行する。 透明性のある執行を確保するため、財団は予算計画と執行の詳細を事前および事後に開示している。 -1. Establishment of the budget and fund execution plan by the foundation +1. 財団による予算と資金執行計画の策定 -2. Disclosure of the budget plans by detailed category +2. 詳細カテゴリー別の予算計画の開示 -3. Disclosure of the execution details after executing the funds through an internal control system by the foundation +3. 財団の内部管理体制による資金執行後の執行内容の開示 -### KAIA Issuance/Distribution Plan +### KAIA発行/配布プラン -As the Klaytn and Finschia ecosystems merge, KLAY and FNSA, which were the base coins of each ecosystem, will also be consolidated into KAIA. Consequently, the issuance and circulation plan for KAIA will inherit the plans from KLAY and FNSA. This section will examine the historical issuance and circulation data of KLAY and FNSA and, based on this, will outline the plan for the issuance and circulation of KAIA. +KlaytnエコシステムとFinschiaエコシステムの統合に伴い、各エコシステムのベースコインであったKLAYとFNSAもKAIAに統合される。 その結果、KAIAの発券・流通計画はKLAYとFNSAの計画を継承することになる。 このセクションでは、KLAYとFNSAの過去の発行・流通データを検証し、それに基づいてKAIAの発行・流通計画を概説する。 -#### KLAY Issuance/Distribution Status +#### KLAY発行/配布状況 -##### KLAY Issuance and Burning Volume +##### KLAYの発行と燃焼量 -On June 24, 2019, a total of 10 billion KLAY were issued on the genesis block at the launch of the mainnet of the Klaytn Blockchain. After the launch of the mainnet, a 3% annual inflation rate was applied based on the genesis issuance volume, newly issuing 9.6 KLAY in each block starting from block 1. Based on the decision of [[KGP-3]](https://govforum.klaytn.foundation/t/kgp-3-reduction-of-klaytn-block-reward/117) in October 2022, 6.4 KLAY have been issued for each block starting from November 13, 2022 (#106444801). As for the KLAY burn volume, a portion of the genesis reserve was burned based on [[KGP-6]](https://govforum.klaytn.foundation/t/kgp-6-proposal-to-establish-a-sustainable-and-verifiable-klay-token-economy/157) of April 16, 2023, and a portion of circulating supply was burned based on the transaction fee burning and buyback burning. As a result, the estimated total supply is 5,971M KLAY at the time of integration, as of June 27, 2024. +2019年6月24日、Klaytnブロックチェーンのメインネットのローンチ時に、ジェネシスブロックで合計100億KLAYが発行された。 メインネットのローンチ後、創世記の発行量に基づいて年率3％のインフレ率が適用され、ブロック1から各ブロックで9.6KLAYが新たに発行された。 2022年10月の[[KGP-3]](https://govforum.klaytn.foundation/t/kgp-3-reduction-of-klaytn-block-reward/117)の決定に基づき、2022年11月13日から各ブロックに6.4KLAYが発行された(#106444801)。 KLAYの燃焼量については、2023年4月16日の[[KGP-6]](https://govforum.klaytn.foundation/t/kgp-6-proposal-to-establish-a-sustainable-and-verifiable-klay-token-economy/157)に基づき発生備蓄の一部を燃焼させ、取引手数料の燃焼および買取燃焼に基づき循環供給量の一部を燃焼させた。 その結果、2024年6月27日時点の総供給量は5,971百万KLAYとなる。 -##### KLAY Private Sale +##### KLAYプライベートセール -KLAY did not conduct an ICO after issuance and only conducted private sales for institutional investors. +KLAYは発行後ICOを実施せず、機関投資家向けのプライベートセールスのみを実施した。 -The private sales were divided into ER (Early Round) and PR (Private Round) from 2018 to 2019. The quantity sold through the private sales was 1,624,251,988 KLAY. The funds were used as operating funds for the mainnet development and operation, and ecosystem expansion. Approximately 1.62 billion KLAY sold through private sales were all unlocked in March 2021 after a step-by-step vesting period, and are already included in the circulating supply. +プライベートセールスは2018年から2019年にかけてER（アーリーラウンド）とPR（プライベートラウンド）に分けられた。 民間販売による販売量は16億2,425万1,988KLAYだった。 この資金は、メインネットの開発と運営、エコシステムの拡大のための運営資金として使われた。 個人間売買で売却された約16億2,000万KLAYは、段階的権利確定期間を経て2021年3月にすべてロック解除され、すでに流通供給に含まれている。 -##### KLAY Circulating Supply +##### KLAY循環供給 -The circulating supply of a cryptocurrency is the total currently tradable supply of the total issued volume of a specific existing cryptocurrency. In other words, it is the amount that is actually traded and distributed in the market. As of June 27, 2024, the expected integration date, the estimated total supply of Klaytn Blockchain will be 5,971M KLAY, excluding the not yet distributed Klaytn Community Fund (KCF)[^4] of 153M KLAY, Klaytn Foundation Fund (KFF)[^5] of 29M KLAY, and KLAY Value Creation Fund (KVCF)[^6] of 2,000M KLAY. These numbers are current estimates and may vary slightly due to block generation status, inflation, and governance proposal approvals. Considering that KVCF requires separate approval from the GC, the circulating supply increases when the execution of KCF or KFF is decided and executed. On the other hand, the circulating supply decreases when it is burned due to transaction fees or buybacks. Accordingly, as of June 27, 2024, the total issued supply is 5,971M KLAY while the circulating supply is 3,789M KLAY. There are no plans to use the KVCF until the time of the merger. The KLAY circulating supply will be inherited by the initial circulating supply of KAIA after the chain and token merger. +暗号通貨の流通供給量とは、特定の既存の暗号通貨の発行量合計のうち、現在取引可能な供給量の合計である。 言い換えれば、市場で実際に取引され、流通する量である。 統合予定日である2024年6月27日の時点で、Klaytnブロックチェーンの推定供給総額は、未分配のKlaytnコミュニティファンド（KCF）[^4]の1億5300万KLAY、Klaytnファウンデーションファンド（KFF）[^5]の2900万KLAY、KLAY価値創造ファンド（KVCF）[^6]の200万KLAYを除き、59億7100万KLAYとなる。 これらの数字は現時点での推定値であり、ブロックの世代交代状況、インフレ、ガバナンス提案の承認などにより若干変動する可能性がある。 KVCFは別途GCの承認が必要であることを考えると、KCFやKFFの実行が決定・実行されると循環供給が増えることになる。 一方、取引手数料や買い戻しで燃やされると、循環供給は減少する。 従って、2024年6月27日現在、発行済み供給量は5,971百万KLAYであり、流通供給量は3,789百万KLAYである。 合併するまでKVCFを利用する予定はない。 KLAYの流通供給量は、チェーンとトークンの統合後、KAIAの初期流通供給量に継承される。 -[^4]: A fund created to revitalize the Klaytn ecosystem and onboard developers, and expenditures are determined after governance approval. +[^4]: Klaytnのエコシステムを活性化し、開発者を乗せるために作られたファンドで、支出はガバナンスの承認後に決定される。 -[^5]: A fund created to operate the existing Klaytn Foundation, and expenditures are also determined after governance approval. +[^5]: 既存のクレイトン財団を運営するために創設された基金で、支出もガバナンスの承認後に決定される。 -[^6]: A reserve created in preparation for the dramatic growth of the Klaytn blockchain. +[^6]: Klaytnブロックチェーンの飛躍的な成長に備えて作られた準備金。 -### FNSA Issuance/Distribution Status +### FNSA発行/配布状況 -#### FNSA Issuance and Burning Volume +#### FNSAの発行と燃焼量 -FNSA of Finschia has been automatically issued in each block at an inflation rate of 15% per year on the current total supply according to the Issuance mechanism of the protocol. Initial total supply was 6,734,458 FNSA. The FNSA issued is distributed to the Network Contribution Reward, Service Contribution Reward, and Reserve at a corresponding ratio of 5:3:2 according to the distribution mechanism. No volume of FNSA was burned. As of June 24 2024, the expected integration date, the estimated total number of FNSA issued through inflation is 7.967M FNSA. +FNSAのFinschiaは、プロトコルの発行メカニズムに従って、現在の総供給量に対して年率15％のインフレ率で各ブロックに自動的に発行されている。 当初の総供給量は6,734,458FNSAであった。 発行されたFNSAは、分配メカニズムに従って、ネットワーク貢献報奨金、サービス貢献報奨金、リザーブに5：3：2の割合で分配される。 FNSAの焼失はなかった。 統合予定日である2024年6月24日の時点で、インフレによって発行されるFNSAの推定総数は796万7,000FNSAである。 -##### FNSA Private Sale +##### FNSAプライベートセール -FNSA did not conduct private sales. +FNSAは個人売買は行っていない。 -##### FNSA Circulating Supply +##### FNSA循環供給 -The total supply and circulating supply of FNSA are equal. In other words, there is no separate uncirculated volume. Additionally, FNSA will set the inflation to 0% and stop new issuance after prior notice before the integration to ensure smooth integration with KLAY. As of June 24 2024, the expected integration date, the estimated total number of FNSA issued through inflation is 7.967M FNSA. The final confirmed total supply of FNSA will be included in the initial distribution of KAIA and inherited according to the agreed-upon exchange ratio. +FNSAの総供給量と循環供給量は等しい。 言い換えれば、非流通の別冊は存在しない。 さらに、FNSAはKLAYとの円滑な統合を確実にするため、統合前にインフレ率を0％に設定し、事前通告後に新規発行を停止する。 統合予定日である2024年6月24日の時点で、インフレによって発行されるFNSAの推定総数は796万7,000FNSAである。 最終的に確認されたFNSAの総供給量は、KAIAの最初の分配に含まれ、合意された交換比率に従って継承される。 -#### KAIA Issuance/Distribution Plan +#### KAIA発行/配布プラン -The KAIA token is created by combining the existing KLAY tokens and FNSA tokens at the time of integration. There may be slight changes in the circulating supply of KLAY and FNSA tokens before the integration through the inflation and burning of block rewards. The circulating supply of the existing KLAY and FNSA at the time of integration will be included in the KAIA circulating supply according to the corresponding exchange rate. Details will be guided through a separate post-announcement by the foundation. The exchange rate for each token to KAIA is as follows: +KAIAトークンは、統合時に既存のKLAYトークンとFNSAトークンを結合して作成される。 統合前のKLAYとFNSAトークンの流通量には、インフレとブロック報酬の焼却によって若干の変化があるかもしれません。 既存のKLAYとFNSAの統合時の流通供給量は、対応する為替レートに従ってKAIAの流通供給量に含まれる。 詳細は、財団が別途事後発表で案内する。 各トークンとKAIAとの交換レートは以下の通り： -- KLAY: KAIA = 1:1 +- クレイ：カイア＝1：1 -- FNSA: KAIA = 148.079656:1 +- FNSA：カイア = 148.079656:1 -The estimated circulating supply at the time of integration and KAIA circulating supply can be explained separately as follows: +統合時の推定循環供給量とKAIAの循環供給量を分けて説明すると以下のようになる： -##### Estimated Supply of KLAY and FNSA +##### KLAYとFNSAの推定供給量 -- Estimated Circulating Supply[^7] - - KLAY: 3,789M KLAY - - FNSA: 7.967M FNSA -- Estimated Uncirculated Volume - - Klaytn Value Creation Fund (KVCF): 2,000M KLAY - - Klaytn Community Fund (KCF): 153M KLAY - - Klaytn Foundation Fund (KFF): 29M KLAY +- 推定循環供給量\[^7］ + - クレイ：3,789mクレイ + - FNSA7.967百万FNSA +- 推定非流通量 + - クレイトン・バリュー・クリエーション・ファンド (KVCF): 2,000M KLAY + - クレイトン・コミュニティ・ファンド（KCF）：153M KLAY + - クレイトン基金（KFF）：2900万KLAY -[^7]: The circulating supply of the Klaytn and Finschia chain may change due to block rewards, etc. until the chain merger. +[^7]: KlaytnチェーンとFinschiaチェーンの流通量は、チェーン統合までの間、ブロック報酬などにより変化する可能性がある。 -##### Estimated KAIA Issuance Volume +##### KAIA発行予定量 -- (+) Conversion of circulating supply (4,968M KAIA) - - Converted KLAY circulating supply: 3,789M \* 1 = 3,789M KAIA - - Converted FNSA circulating supply: 7.967M \* 148.079656 FNSA = 1,179M KAIA -- (-) Burning of uncirculated volume - - KVCF + KCF + KFF = 2,182M KAIA = Burn 1,382M KAIA out of 2,182M KAIA -- (+) Conversion[^8] of uncirculated volume remaining after burning into circulating supply - - LINE NEXT Delegation: 330M KAIA - - Kaia Ecosystem Fund: 270M KAIA - - Kaia Infrastructure Fund: 200M KAIA +- (+) 循環供給への転換 (4,968百万KAIA) + - KLAY循環供給量に換算：3,789m ╱ 1 = 3,789m カイア + - FNSA循環供給量を換算：7.967百万㍑\* 148.079656百万FNSA = 1,179百万Kaia +- (-)未循環量の燃焼 + - KVCF + KCF + KFF = 21億8200万KAIA = 21億8200万KAIAのうち13億8200万KAIAを燃やす +- (+) 燃焼後に残る未循環量を循環供給量に変換[^8]する。 + - LINEネクスト・デレゲーション330M KAIA + - カイア・エコシステム・ファンド：2億7000万KAIA + - カイア・インフラストラクチャー・ファンド：2億カイア -Since the entire uncirculated amount gets burned at the time of KAIA conversion, the total supply and the circulating supply match. The estimated circulating supply at this time of integration is about 5,768M KAIA. +KAIAの換金時に未流通分はすべて焼却されるため、総供給量と流通供給量は一致する。 この統合時点での推定流通量は約57億6800万KAIAである。 -However, the mentioned numbers are based on the issuance and circulating supply estimation as of May 14, 2024, GST, and the final figures may change depending on the inflation of Klaytn and Finschia. +ただし、記載された数字は2024年5月14日時点の発行および流通供給量（GST）に基づいており、最終的な数字はKlaytnとFinschiaのインフレ次第で変わる可能性がある。 -The circulating supply after the token merge may increase according to the measures mentioned in [Kaia Blockchain Fund](#kaia-blockchain-fund) or decrease due to burning. However, as specified in the relevant section, any additional supply must be announced in advance or approved by governance. +トークン統合後の流通量は、【Kaia Blockchain Fund](#kaia-blockchain-fund)に記載された措置により増加することもあれば、焼失により減少することもあります。 ただし、関連セクションに明記されているように、追加供給は事前に発表されるか、ガバナンスによって承認されなければならない。 -[^8]: Future circulation will only change due to inflation and new burning models. Incorporation of the circulation amount of the fund does not necessarily mean liquidation, and it will be executed transparently only within the scope of governance approval. +[^8]: 将来の流通量は、インフレと新しい燃焼モデルによって変わるだけだ。 ファンドの流通額の組み入れは、必ずしも清算を意味するものではなく、ガバナンスの承認の範囲内でのみ透明性をもって実行される。 -#### Treasury Rebalance Plan +#### 財務省のリバランス計画 -With the launch of the Kaia Blockchain, the new tokenomics mentioned in the Tokenomics section will be applied. This involves a massive scale of tokens, including the conversion of existing FNSA and KLAY circulations to KAIA, new fund allocations, and burned tokens. A treasury rebalance event will occur only once at the launch, which is a critical process that must be systematic, transparent, and auditable. To ensure this, all procedures will be meticulously recorded in smart contracts. Moreover, given the large volume of tokens involved, it is vital to apply various technologies to prevent errors (such as fat finger errors) and minimize security risks. The application of the new tokenomics is structured to proceed safely only after several conditions are met. Ultimately, the new tokenomic state is achieved through the consensus of validators, relying on the highest level of security available on the blockchain. +カイア・ブロックチェーンのローンチに伴い、トークノミクスのセクションで述べた新しいトークノミクスが適用される。 これには、既存のFNSAとKLAYのKAIAへの転換、新たな基金の割り当て、燃やされたトークンなど、大規模なトークンが含まれる。 トレジャリー・リバランス・イベントは、立ち上げ時に一度だけ発生する。これは、体系的で透明性があり、監査可能でなければならない重要なプロセスである。 これを確実にするため、すべての手続きはスマート・コントラクトに綿密に記録される。 さらに、大量のトークンを扱うため、エラー（ファット・フィンガー・エラーなど）を防止し、セキュリティ・リスクを最小限に抑えるためのさまざまな技術の適用が不可欠である。 新しいトークノミクスの適用は、いくつかの条件が満たされた後にのみ安全に進められる構造になっている。 最終的に、新しいトークノミックの状態は、ブロックチェーンで利用可能な最高レベルのセキュリティに依存するバリデータのコンセンサスによって達成される。 -The overall process is as follows. A contract named TreasuryRebalance is deployed, followed by the uploading of a rebalance configuration into this contract. All stakeholders whose balance will be altered must approve of the configuration. Once all stakeholders have approved, block validators check the validity of the contract at the hardfork block at which the rebalance event takes place. Provided all conditions are met, block validators execute the rebalance event and reach a consensus. After the event was successful, an execution receipt which block providers output will be uploaded to the contract so that anyone can view the rebalance result. +全体的なプロセスは以下の通りである。 TreasuryRebalanceという名前のコントラクトがデプロイされ、続いてリバランスのコンフィギュレーションがこのコントラクトにアップロードされる。 バランスが変更されるすべての利害関係者は、その構成を承認しなければならない。 すべてのステークホルダーが承認すると、ブロック・バリデーターはリバランス・イベントが行われるハードフォーク・ブロックでコントラクトの有効性をチェックする。 すべての条件が満たされると、ブロック・バリデーターはリバランス・イベントを実行し、コンセンサスを得る。 イベントが成功した後、ブロックプロバイダーが出力した実行レシートがコントラクトにアップロードされ、誰でもリバランスの結果を見ることができるようになる。 -TreasuryRebalance contract is implemented as a finite state machine and has the following states: +TreasuryRebalance契約は有限ステートマシンとして実装され、以下の状態を持つ： -- Initialized: right after the deployment. In this state, a list of addresses whose balance will be zeroed, namely “Zeroed”, and addresses whose balance will be allocated, namely “Allocated”, can be registered. +- 初期化：デプロイ直後。 この状態で、残高がゼロになるアドレス「ゼロ済」と、残高が割り当てられるアドレス「割り当て済」のリストを登録できる。 -- Registered: after all Zeroed and Allocated has been registered. In this state, there cannot be further registration. All owners of Zeroed must send a consent transaction, which indicates that they approve that their balance will be burnt. +- Registered（登録済み）：すべてのZeroedとAllocatedが登録された後。 この状態では、それ以上の登録はできない。 Zeroedのすべての所有者は、自分の残高が焼却されることを承認することを示す同意トランザクションを送信しなければならない。 -- Approved: after all consents have been collected, the contract can enter Approved state. Any change in this contract is prohibited until the hardfork block passes. +- 承認済み：すべての同意が集まった後、契約は承認済み状態に入ることができる。 ハードフォーク・ブロックが通過するまで、この契約の変更は禁止されている。 -- Finalized: After the hardfork block, the rebalance result, namely “memo”, is recorded and the contract is finalized. The contract is rendered immutable. +- 確定：ハードフォーク・ブロックの後、リバランスの結果、すなわち「メモ」が記録され、契約が確定する。 契約は不変となる。 -The state transition is only possible in the following order. However, there can be a “reset” where all data is deleted and the state goes back to initialized. +状態遷移は以下の順序でのみ可能である。 しかし、すべてのデータが削除され、状態が初期化された状態に戻る「リセット」は可能である。 ![](/img/misc/state-machine.jpg) -All block validators validate the contract state at the hardfork block. The rebalance event takes place only in the Approved state where no further change can happen. Since this event depends on the consensus of all validators, it is ensured that all validators reach the same world state after this event. +すべてのブロックバリデーターは、ハードフォークブロックの契約状態を検証する。 リバランス・イベントは、それ以上の変更ができない承認された状態でのみ行われる。 このイベントはすべてのバリデータの合意に依存するため、このイベントの後、すべてのバリデータが同じワールドステートに到達することが保証される。 -All block validators produce the result of the rebalance event called memo in their validator log. The memo is uploaded to the TreasuryRebalance contract during Finalize. memory is a JSON-formatted string which contains information such as the balance of Zeroed before the rebalance, the balance of Allocated after the rebalance, and the burnt amount. The admin of treasury rebalance validates the consistency of the memo and uploads it to TreasuryRebalance contract. After finalization, the contract becomes immutable forever. +すべてのブロックバリデータは、memo というリバランスイベントの結果をバリデータログに記録する。 メモは、Finalize 中に TreasuryRebalance 契約にアップロードされる。 memoryはJSON形式の文字列で、リバランス前のZeroed残高、リバランス後のAllocated残高、バーント額などの情報が含まれる。 トレジャリー・リバランスの管理者はメモの整合性を検証し、TreasuryRebalance 契約にアップロードする。 確定後、契約は永久に不変となる。 -## Governance +## ガバナンス -### Governance Core Components +### ガバナンスのコア・コンポーネント -Kaia Governance operates based on three main components: Kaia Community, Kaia Council, and Kaia Foundation. Kaia Community encompasses all KAIA holders, who have the right to express their opinions on Kaia Mainnet operations via the governance forum and social channel. Kaia Council represents the community and directly participates in the governance decisions of the project based on the coins it holds and voting rights delegated from the community. Lastly, Kaia Foundation utilizes its expertise in blockchain and Web3 technology to provide evidence, based on professional knowledge and data that could assist Kaia Council in making decisions and implementing the decisions made through governance. Kaia Governance ensures effective decision-making and execution with this systematic structure and pursues transparent and fair community operation. +カイア・ガバナンスは3つの主要な構成要素に基づいて運営されている：カイア・コミュニティ、カイア・カウンシル、カイア財団である。 カイア・コミュニティは、ガバナンス・フォーラムやソーシャル・チャンネルを通じてカイア・メインネットの運営について意見を述べる権利を持つ、すべてのKAIAホルダーを包含しています。 カイア評議会はコミュニティを代表し、保有するコインとコミュニティから委任された議決権に基づき、プロジェクトの統治決定に直接参加する。 最後に、カイア財団はブロックチェーンとWeb3テクノロジーの専門知識を活用し、専門的な知識とデータに基づいたエビデンスを提供することで、カイア評議会の意思決定とガバナンスによる意思決定の実行を支援する。 カイア・ガバナンスは、この体系的な仕組みによって効果的な意思決定と執行を保証し、透明で公正なコミュニティ運営を追求します。 -### Governance System +### ガバナンス・システム -Kaia Governance respects the diversity of the governance system and seeks to create a diverse governance ecosystem through the coexistence, cooperation, and competition of multiple systems. It encompasses various forms of governance found in the real world ranging from representative democracy, where each individual grants voting rights to decision-makers to representatives, the DAO system, where all members participate in the decision-making process of the organization, and capitalism, where shareholders influence company decisions through representatives designated by shareholders. Kaia Governance seeks to lay the foundation for a transparent and fair blockchain ecosystem through this comprehensive approach. Its vision is to build a stronger and more flexible system by combining the strengths of multiple governance models. +カイア・ガバナンスは、ガバナンス・システムの多様性を尊重し、複数のシステムの共存・協力・競争を通じて、多様なガバナンス・エコシステムを創造することを目指しています。 各個人が意思決定者への議決権を代表者に与える代議制民主主義、組織の意思決定プロセスに全メンバーが参加するDAOシステム、株主が指定した代表者を通じて会社の意思決定に影響を与える資本主義など、現実世界で見られるさまざまなガバナンス形態を包含している。 カイア・ガバナンスは、このような包括的なアプローチを通じて、透明で公正なブロックチェーンエコシステムの基礎を築こうとしている。 そのビジョンは、複数のガバナンス・モデルの長所を組み合わせることで、より強力で柔軟なシステムを構築することである。 -### Community-Centered Governance +### 地域中心のガバナンス -At Kaia, organizations based on various governance systems will participate in governance, express their opinions, and thereby prove the excellence of their systems. More holders and assets will be concentrated in systems that have proven their greater contribution to the sustainable development of the Kaia ecosystem, resulting in more decision-making authority being concentrated in members with successful systems. Also, the council members will replicate successful governance, expanding the system. +カイアでは、さまざまなガバナンス・システムに基づく組織がガバナンスに参加し、意見を表明することで、そのシステムの優秀性を証明する。 カイア生態系の持続可能な発展への貢献度が高いことが証明されたシステムに、より多くの保有者と資産が集中することになり、その結果、成功したシステムを持つメンバーに、より多くの決定権が集中することになる。 また、評議会のメンバーは成功したガバナンスを再現し、システムを拡大する。 -As time passes, optimized governance systems for new trends will emerge. Kaia Governance will continue to develop focusing on the optimized governance system in line with these changes, which will contribute to an increased efficiency of the entire ecosystem. In the process, Kaia will present an example of a governance system with both diversity and flexibility and will lead the innovation in governance in the blockchain ecosystem. +時が経てば、新しいトレンドに最適化されたガバナンス・システムが出現するだろう。 カイア・ガバナンスは、エコシステム全体の効率向上に貢献する、このような変化に合わせて最適化されたガバナンス・システムに焦点を当てて開発を続けていく。 その過程でカイアは、多様性と柔軟性を併せ持つガバナンス・システムの例を提示し、ブロックチェーン・エコシステムにおけるガバナンスの革新をリードしていく。 -Kaia builds the Kaia Governance system based on the belief that Web3 innovation has its roots in the participation of various communities. In line with this hypothesis, greater importance is given to community input in the decision-making process. As a result, it ensures that decision-making power is fairly distributed among different council members. Through this approach, Kaia Governance aims to foster sustainable development and innovation in Web3 by prioritizing the voices of the community and creating a more inclusive and diverse decision-making environment. +カイアは、Web3イノベーションの根源は様々なコミュニティの参加にあるという信念に基づき、カイア・ガバナンス・システムを構築しています。 この仮説に沿い、意思決定プロセスにおいてコミュニティの意見がより重要視されている。 その結果、意思決定権が各議員に公平に配分されることになる。 このアプローチを通じて、カイア・ガバナンスは、コミュニティの声を優先し、より包括的で多様な意思決定環境を作ることで、Web3の持続可能な発展とイノベーションを促進することを目指しています。 -### Governance Direction +### ガバナンスの方向性 -Kaia Governance adopts a strategy of adjusting the pace of the governance process, considering changes in the cryptocurrency market and the development stage of the Kaia ecosystem. The discussion and processing speed of the agenda are determined through a consensus between the foundation, council, and community, which reflects the rapidly changing cryptocurrency market situation and the ongoing growth process of Project Kaia. Currently, in 2024, the ecosystem of Project Kaia is still in the development stage despite the rapid progress over the past five years, and Kaia takes a governance approach with growth as its priority. By establishing a structure where the agendas can be discussed and decided quickly, the project plans to proactively respond to the changing market environments and accelerate the growth of the ecosystem. +カイア・ガバナンスは、暗号通貨市場の変化とカイア・エコシステムの発展段階を考慮し、ガバナンス・プロセスのペースを調整する戦略を採用しています。 アジェンダの議論と処理速度は、財団、評議会、コミュニティの合意によって決定される。これは、急速に変化する暗号通貨市場の状況とプロジェクト・カイアの継続的な成長過程を反映したものである。 2024年現在、プロジェクト・カイアのエコシステムは、過去5年間の急速な進展にもかかわらず、まだ発展段階にあり、カイアは成長を最優先とするガバナンス・アプローチをとっている。 このプロジェクトは、議題を迅速に議論し決定できる体制を確立することで、変化する市場環境に積極的に対応し、エコシステムの成長を加速させる計画である。 -## Technology +## テクノロジー -### Overview +### 概要 -Kaia Blockchain has three primary technical objectives. +カイア・ブロックチェーンには3つの主要な技術的目的がある。 -First, performance is paramount. The blockchain emphasizes rapid finality, ensuring that users receive immediate responses. It also aims to process a high volume of user requests quickly, enabling blockchain applications (dApps) on Kaia Blockchain to offer a user experience comparable to conventional mobile apps. +まず、パフォーマンスが最重要だ。 ブロックチェーンは迅速性を重視し、ユーザーが即座に返答を受け取れるようにしている。 また、大量のユーザーリクエストを迅速に処理することで、カイアブロックチェーン上のブロックチェーンアプリケーション（dApps）が従来のモバイルアプリに匹敵するユーザーエクスペリエンスを提供できるようになることを目指している。 -Second, transparency is crucial. Decision-making at the layer 1 protocol has widespread implications across the ecosystem. Therefore, decisions should be made transparently through on-chain governance. Furthermore, Kaia Blockchain intends to publicly disclose all elements related to the operation of the blockchain network, ensuring that it is fully verifiable by anyone. +第二に、透明性が重要である。 レイヤー1のプロトコルにおける意思決定は、エコシステム全体に広く影響を及ぼす。 したがって、オンチェーン・ガバナンスを通じて透明性のある意思決定がなされるべきである。 さらにカイア・ブロックチェーンは、ブロックチェーン・ネットワークの運用に関連するすべての要素を公開し、誰でも完全に検証できるようにするつもりだ。 -Third, sustainability is essential. Operating a blockchain over the long term presents various challenges, such as the continuous increase in block data and the economics necessary to sustain network operations. Kaia Blockchain is designed to reduce operational costs and increase profitability, ensuring its long-term viability. +第三に、持続可能性が不可欠である。 ブロックチェーンを長期にわたって運用するには、ブロックデータの継続的な増加や、ネットワーク運用を維持するために必要な経済性など、さまざまな課題がある。 カイア・ブロックチェーンは、運用コストを削減し、収益性を高めるよう設計されており、長期的な存続が可能である。 -The forthcoming content will cover two main topics. The first is the genesis of the Kaia Blockchain, describing the technologies applied, including consensus mechanisms, smart contracts, and on-chain governance, which collectively reflect the extensive technical considerations made to achieve its goals. The second topic is the evolution of the Kaia Blockchain. It will introduce a variety of new technologies that are planned for the near future, including maintaining high performance while allowing anyone to operate a validator node in a permissionless manner, enhancing transparency in block transaction ordering to mitigate the negative effects of Maximal Extractable Value (MEV), and block archiving techniques for swift verification of historical blocks. These innovations will set the Kaia Blockchain apart, enhancing its uniqueness and attractiveness. +今後予定されている内容は、主に2つのトピックを取り上げる。 1つ目は、カイア・ブロックチェーンの創世記であり、コンセンサスメカニズム、スマートコントラクト、オンチェーンガバナンスなど、適用された技術について説明している。 つ目のトピックは、カイア・ブロックチェーンの進化である。 高性能を維持しつつ、誰でもバリデータノードをパーミッションレスで運用できるようにすること、MEV（Maximal Extractable Value）の悪影響を緩和するためにブロック取引順序の透明性を高めること、過去のブロックを迅速に検証するためのブロックアーカイブ技術など、近い将来に予定されているさまざまな新技術を紹介する。 これらのイノベーションは、カイア・ブロックチェーンを際立たせ、その独自性と魅力を高めるだろう。 -### Birth of Kaia Blockchain +### カイア・ブロックチェーンの誕生 -To achieve the aforementioned technical goal, Kaia Blockchain is launched with various technical features. Specifically, the performance goal is facilitated by consensus and network topology, and the transparency and the sustainability is facilitated by smart contracts and on-chain governance. The initial performance of Kaia Blockchain is as follows: +前述の技術的な目標を達成するため、カイア・ブロックチェーンは様々な技術的特徴を備えて登場した。 具体的には、パフォーマンス目標はコンセンサスとネットワーク・トポロジーによって促進され、透明性と持続可能性はスマート・コントラクトとオンチェーン・ガバナンスによって促進される。 カイア・ブロックチェーンの初期性能は以下の通り： -- Process 4,000 transactions/sec (TPS) +- 4,000トランザクション/秒(TPS) -- Instant transaction finality +- 取引の即時確定 -- Creation time of 1 block/second +- 1ブロック/秒の作成時間 -#### Consensus and Networking +#### コンセンサスとネットワーク -Blockchains use a “distributed ledger,” which consists of a connected network between individuals with several network participants to record and manage the transaction information. Each blockchain adopts a consensus algorithm that is most suitable for it, with the aim of efficient and smooth consensus on transaction validation and block generation among network participants. These consensus algorithms help the system to reach a consensus on the correct state, even if there is a system failure or malicious attack on the network. They play an important role in ensuring the integrity and stability of the blockchain. +ブロックチェーンは「分散型台帳」を使用し、複数のネットワーク参加者による個人間の接続されたネットワークで構成され、取引情報を記録・管理する。 各ブロックチェーンは、そのブロックチェーンに最適なコンセンサスアルゴリズムを採用し、ネットワーク参加者間での取引検証とブロック生成に関する効率的かつ円滑なコンセンサスを目指している。 これらのコンセンサス・アルゴリズムは、システム障害やネットワークへの悪意ある攻撃があったとしても、システムが正しい状態のコンセンサスに達するのを助ける。 ブロックチェーンの完全性と安定性を確保する上で重要な役割を担っている。 -##### IBFT (Istanbul Byzantine Fault Tolerance) +##### IBFT（イスタンブール・ビザンチン・フォールト・トレランス） -Kaia aims to become an enterprise-support and service-oriented platform. Therefore, the finality problem must be solved, with the network allowing many nodes to participate in the network. For this purpose, Kaia uses an optimized version of Istanbul BFT, which implements PBFT with modifications to suit the characteristics of blockchain networks. +カイアはエンタープライズ・サポートとサービス指向のプラットフォームを目指している。 したがって、多くのノードがネットワークに参加できるようにして、最終性の問題を解決しなければならない。 この目的のために、カイアはブロックチェーン・ネットワークの特性に合わせて修正されたPBFTを実装するイスタンブールBFTの最適化バージョンを使用する。 -Kaia Blockchain has three types of nodes: Consensus Node(CN), Proxy Nodes(PN), and Endpoint Nodes (EN). CN is managed by a validator and is responsible for block creation. These blocks are verified by all the nodes within the network. +カイア・ブロックチェーンには3種類のノードがある：コンセンサスノード（CN）、プロキシノード（PN）、エンドポイントノード（EN）である。 CNはバリデータによって管理され、ブロックの作成を担当する。 これらのブロックは、ネットワーク内のすべてのノードによって検証される。 ![](/img/misc/kaia-nodes.jpg) -Kaia Blockchain has adopted and enhanced Istanbul BFT to achieve rapid finality. Since validation and consensus occur with each block, there are no forks, and the finality of the blocks where consensus is reached is immediately guaranteed. Block proposers are selected in an unpredictable manner using a Verifiable Random Function (VRF), thereby offering high resistance to centralized Denial of Service (DoS) attacks. CN must deposit a certain amount of tokens, maintaining reasonable networking costs while enabling easy operation by any EN, thus enhancing the scalability of the blockchain network usage. +カイア・ブロックチェーンは、イスタンブールBFTを採用・強化し、迅速なファイナリティを実現した。 検証とコンセンサスはブロックごとに行われるため、フォークが発生せず、コンセンサスに達したブロックの最終性は即座に保証される。 ブロック提案者は、検証可能ランダム関数（VRF）を使用して予測不可能な方法で選択されるため、集中型サービス拒否（DoS）攻撃に対して高い耐性を提供します。 CNは一定量のトークンを預け入れる必要があり、合理的なネットワークコストを維持しつつ、どのENでも簡単に運用できるようにすることで、ブロックチェーンのネットワーク利用のスケーラビリティを高めている。 -##### Multi-channel Broadcast +##### 多チャンネル放送 -Network latency is greatly affected by network congestion. Assuming the throughput of the network is constant, network latency increases proportionally to the increase in the number of transactions. General users of mobile apps or web services do not tolerate response times longer than a few seconds, and there is no reason to assume that blockchain services will have greater user patience. +ネットワークの待ち時間は、ネットワークの混雑に大きく影響される。 ネットワークのスループットが一定であると仮定すると、ネットワークの待ち時間はトランザクション数の増加に比例して増加する。 モバイルアプリやウェブサービスの一般ユーザーは、数秒以上のレスポンスタイムを許容しない。 -Kaia Blockchain adopts a multi-channel approach to deal with network congestion. By allocating separate propagation channels to transactions and blocks, the Kaia network can propagate newly created blocks in a timely manner even when the network faces severe congestion due to a large number of transactions. In turn, Kaia guarantees the dApps on the network to continue responding to end-user requests despite intermittent network traffic surges. +カイア・ブロックチェーンは、ネットワークの混雑に対処するためにマルチチャネル・アプローチを採用している。 トランザクションとブロックに別々の伝搬チャネルを割り当てることで、Kaiaネットワークは、ネットワークが大量のトランザクションによる深刻な輻輳に直面しても、新しく作成されたブロックをタイムリーに伝搬することができる。 さらにカイアは、断続的なネットワークトラフィックの急増にもかかわらず、ネットワーク上のdAppsがエンドユーザーのリクエストに応答し続けることを保証する。 -##### Consensus Process +##### コンセンサス・プロセス -The consensus process consists of the following three stages: +コンセンサスのプロセスは、以下の3段階からなる： -1. Election: The Committee is composed of Consensus Nodes (CNs) that participate in achieving consensus. This is a similar task to the leader election in a general distributed system. The proposer is randomly selected through VRF since knowing them in advance can make them vulnerable to targeted DoS (denial of service). +1. 選挙委員会は、コンセンサス達成に参加するコンセンサスノード（CN）で構成される。 これは、一般的な分散システムにおけるリーダー選出と同様の作業である。 提案者を事前に知っていると、標的型DoS（サービス拒否）に対して脆弱になる可能性があるため、提案者はVRFを通じてランダムに選ばれる。 -2. Block Generation: Elected proposers create a block and make a proposal to the committee. The block proposal made through the P2P network is sent to the committee. +2. ブロックの生成：選出された提案者がブロックを作成し、委員会に提案する。 P2Pネットワークを通じて提案されたブロックは、委員会に送られる。 -3. Block Verification: The committee verifies and signs the block proposed by the proposer. A block is complete when more than a quorum of signatures is collected. +3. ブロックの検証：委員会は、提案者によって提案されたブロックを検証し、署名する。 ブロックは、定足数以上の署名が集まった時点で完了となる。 -#### Account Model and Smart Contract +#### アカウントモデルとスマートコントラクト -Kaia Blockchain offers scalability in service development through its expanded account model and smart contract capabilities. Smart contracts on the blockchain enhance the efficiency of transactions and contracts between individuals through contract automation, and the use of smart contracts has had a significant impact on the blockchain and dApp ecosystem. Contract conditions can be coded into smart contracts and automatically executed, solving the trusted intermediary issue. Smart contracts have allowed the blockchain ecosystem to create new business models and economic systems by reducing the cost and time required to complete transactions. Kaia Blockchain supports a distributed virtual machine for executing smart contracts, which is designed to be fast and efficient, providing the best and swiftest development environment for dApp developers and projects. +カイア・ブロックチェーンは、拡張アカウントモデルとスマートコントラクト機能により、サービス開発のスケーラビリティを提供する。 ブロックチェーン上のスマートコントラクトは、契約の自動化を通じて個人間の取引や契約の効率を高め、スマートコントラクトの利用はブロックチェーンとdAppのエコシステムに大きな影響を与えている。 契約条件をスマートコントラクトにコード化し、自動的に実行することで、信頼できる仲介者の問題を解決できる。 スマートコントラクトによって、ブロックチェーンエコシステムは、取引完了に必要なコストと時間を削減することで、新たなビジネスモデルと経済システムを生み出すことができるようになった。 カイアブロックチェーンは、スマートコントラクトを実行するための分散型仮想マシンをサポートしており、高速かつ効率的に設計されているため、dApp開発者やプロジェクトに最適かつ迅速な開発環境を提供します。 -##### Account Model +##### アカウントモデル -The Kaia Blockchain supports an expanded form of the Account Model. Inside the implementation of an EOA (Externally Owned Account) account, it is possible to store an Account Key, which is an expanded form of the EOA's Public Key. This information allows users to replace the Private Key associated with that account. Additionally, users can register multiple Private Keys for use in Multi-Signature setups or to separate roles among different Private Key users. The roles provided include the authority to create transactions, update registered keys in the Account, and permissions solely for fee delegation purposes. +カイア・ブロックチェーンは、アカウント・モデルの拡張型をサポートしている。 EOA（Externally Owned Account）アカウントの実装内部には、EOAの公開鍵を拡張した形であるアカウント鍵を格納することができる。 この情報により、ユーザはそのアカウントに関連する秘密鍵を置き換えることができる。 さらに、ユーザーは複数の秘密鍵を登録し、マルチシグネチャ設定に使用したり、異なる秘密鍵ユーザー間で役割を分担したりすることができる。 提供される役割には、トランザクションを作成する権限、アカウントに登録された鍵を更新する 権限、および料金委任のみを目的とする権限が含まれる。 -##### Kaia Virtual Machine (KVM) +##### カイア仮想マシン（KVM） -The current version of Kaia Virtual Machine (KVM) is a derivative of the Ethereum Virtual Machine (EVM). It supports all Opcodes of the Ethereum Virtual Machine equally while providing additional precompiled contracts unique to the Kaia Virtual Machine. To prevent the additional precompiled contracts of Kaia from colliding with the precompiled contracts of the Ethereum Virtual Machine, the precompiled contract addresses of Kaia are given in a decreasing order starting from 0x03ff. +現在のバージョンのカイア仮想マシン（KVM）は、イーサリアム仮想マシン（EVM）の派生版である。 Ethereum仮想マシンのすべてのOpcodeを同等にサポートし、Kaia仮想マシンに固有のプリコンパイルされたコントラクトを追加提供します。 Kaiaのプリコンパイルされた追加コントラクトがイーサリアム仮想マシンのプリコンパイルされたコントラクトと衝突するのを防ぐため、Kaiaのプリコンパイルされたコントラクトアドレスは0x03ffから始まる小さい順に与えられています。 -Kaia Virtual Machine provides several methods to write and run Smart Contracts on the Kaia network. Kaia supports Solidity and maintains interoperability with Ethereum development toolkits such as Remix, Hardhat, Truffle, and Foundry. A smart contract written with Solidity can be compiled using the existing Solidity compiler and can be run on Kaia without additional work. Solidity is the de facto standard contract programming language on Ethereum and is supported by an active community. Therefore, Kaia Blockchain supports the Solidity language to provide the most familiar development environment for Ethereum dApp developers allowing them to easily migrate their work. +Kaia仮想マシンは、Kaiaネットワーク上でスマートコントラクトを書き、実行するためのいくつかの方法を提供します。 KaiaはSolidityをサポートし、Remix、Hardhat、Truffle、Foundryなどのイーサリアム開発ツールキットとの相互運用性を維持しています。 Solidityで書かれたスマートコントラクトは、既存のSolidityコンパイラを使ってコンパイルすることができ、追加作業なしにKaia上で実行することができる。 Solidityはイーサリアムにおける事実上の標準契約プログラミング言語であり、活発なコミュニティによってサポートされている。 そのため、Kaia BlockchainはSolidity言語をサポートし、イーサリアムのdApp開発者に最も馴染みのある開発環境を提供することで、開発作業を容易に移行できるようにしています。 -##### System contracts +##### システム契約 -Kaia Blockchain manages a part of protocol as smart contracts, which are called system contracts. Block validators directly or indirectly interact with system contracts. System contracts facilitate transparent and easy-to-access protocol operation. There is a specification that defines a Registry contract which will contain new system contracts. It can be viewed by a REST API and thus users can continuously check and monitor system contracts. +カイア・ブロックチェーンは、プロトコルの一部をシステム契約と呼ばれるスマートコントラクトとして管理している。 ブロックバリデータは、システムコントラクトと直接的あるいは間接的に相互作用する。 システム・コントラクトは、透明でアクセスしやすいプロトコル運用を容易にする。 新しいシステム契約を含むレジストリ契約を定義する仕様がある。 これはREST APIで見ることができるため、ユーザーはシステム・コントラクトを継続的にチェックし、監視することができる。 -Since system contracts can directly impact the blockchain protocol, they need to be managed in a highly secure manner. They are internally classified as the highest level of security, and thus they are managed as a multi-sig by default. Storing of keys and signing of transactions are performed in an isolated device which is never connected to online. In addition, there are internal manuals and tools for systematic management of system contracts. +システム・コントラクトはブロックチェーンのプロトコルに直接影響を与える可能性があるため、高度に安全な方法で管理する必要がある。 これらは内部的に最高レベルのセキュリティとして分類されているため、デフォルトでマルチシグとして管理される。 鍵の保管とトランザクションの署名は、オンラインに接続されることのない隔離されたデバイスで行われる。 さらに、システム契約を体系的に管理するための社内マニュアルやツールもある。 -These are essential system contracts: +これらは不可欠なシステム契約である： -- AddressBook: a contract which manages a list of validators. +- AddressBook: バリデータのリストを管理するコントラクト。 -- GovParam: a contract for on-chain governance on network parameters . +- GovParam: ネットワークパラメータに関するオンチェーンガバナンスのための契約. -- SimpleBlsRegistry: a BLS key storage for validators. +- SimpleBlsRegistry: バリデータ用のBLSキーストレージ。 -#### On-Chain Governance +#### オンチェーン・ガバナンス -On-chain governance is an on-chain decision-making system among stakeholders. On-chain governance is implemented in a structure including smart contracts and has several advantages over off-chain governance. The entire process of governance is transparently recorded, and anyone can check the progress of governance on-chain (transparency). Since the governance process proceeds solely according to the contract logic, the voting and results cannot be tampered with maliciously (integrity). Therefore, the intentions of the participants can be reflected without any distortion in the governance process. Also, it is impossible to deny a vote because no one except the voter can vote (non-repudiation). As a result, the voters become accountable for their voting behaviors. An environment where the voting results can be enforced compulsorily or automatically can be created (enforceability). Without enforceability, the implementer may ignore the voting results, which will eventually reduce the credibility of governance. +オンチェーンガバナンスとは、ステークホルダー間のオンチェーンでの意思決定システムのことである。 オンチェーンガバナンスはスマートコントラクトを含む構造で実装され、オフチェーンガバナンスに比べていくつかの利点がある。 ガバナンスの全過程が透明性をもって記録され、誰でもオンチェーンでガバナンスの進捗状況を確認することができる（透明性）。 ガバナンス・プロセスは契約論理のみに従って進行するため、投票や結果が悪意を持って改ざんされることはない（完全性）。 したがって、参加者の意向をガバナンス・プロセスに歪みなく反映させることができる。 また、投票者以外は投票できないので、投票を拒否することは不可能である（否認防止）。 その結果、有権者は自分の投票行動に責任を持つようになる。 投票結果を強制的または自動的に執行できる環境を作ることができる（執行可能性）。 強制力がなければ、実施者は投票結果を無視する可能性があり、最終的にはガバナンスの信頼性を低下させることになる。 -Kaia Blockchain implements an on-chain governance system satisfying the above properties. The on-chain governance of Kaia Blockchain is designed to be fair and to ensure diverse opinions are shared. Voting entities can vote on all agenda items. Voting rights are calculated in proportion to the amount of staking. However, there is a cap on voting rights to prevent minority opinions from being ignored. Users can delegate their staking amount to other voters. +カイア・ブロックチェーンは、上記の特性を満たすオンチェーン・ガバナンス・システムを実装している。 カイア・ブロックチェーンのオンチェーン・ガバナンスは、公正で多様な意見が共有されるように設計されている。 投票権を有する団体は、すべての議題について投票することができる。 議決権は賭け金額に応じて計算される。 ただし、少数意見が無視されるのを防ぐため、投票権には上限が設けられている。 ユーザーは自分の賭け金額を他の投票者に委任することができる。 -The voting process is transparent and open. Types of agendas include text agendas, parameter change agendas, and fund expense agendas. For some agendas, such as parameter change agendas, a transaction can be attached to the agenda. In this case, once the agenda is passed, the transaction will be automatically executed. This allows the mandatory performance of governance by automatically reflecting the changes in network parameters as well as executing funds through governance. +投票プロセスは透明でオープンだ。 議題の種類には、テキスト議題、パラメータ変更議題、資金支出議題などがある。 パラメータ変更アジェンダのようないくつかのアジェンダでは、アジェンダにトランザクショ ンを添付することができる。 この場合、アジェンダが可決されれば、トランザクションは自動的に実行される。 これにより、ネットワーク・パラメーターの変化を自動的に反映し、ガバナンスを強制的に実行することができる。 -Other than this, various detailed policy decisions, such as restrictions on voting rights, voting periods, and voter participation, are needed for a comprehensive and fair decision-making system. A highly reliable network will be built by establishing a governance system that harmoniously reflects the needs and expectations of various stakeholders. +これ以外にも、選挙権の制限、投票期間、有権者の参加など、さまざまな細かい政策決定が、包括的で公正な意思決定システムには必要である。 信頼性の高いネットワークは、さまざまなステークホルダーのニーズと期待を調和的に反映するガバナンス・システムを確立することによって構築される。 -##### Governance Process +##### ガバナンス・プロセス -The overall governance process of Kaia is as follows: +カイアの全体的なガバナンス・プロセスは以下の通りである： -1. Discussion: Improve the agenda through free discussion among all participants off-chain. +1. ディスカッションオフチェーンでの参加者全員による自由なディスカッションを通じて、アジェンダを改善する。 -2. On-Chain Agenda Voting: Register the agenda on-chain and proceed with voting. +2. オンチェーンでの議題投票オンチェーンで議題を登録し、投票に進む。 -3. Reflect Results (Activation): Implement when agenda items are approved. +3. 結果の反映（活性化）：議題が承認されたら実施する。 ![](/img/misc/gov-process.jpg) -Agendas registered on-chain go through several states until the voting is complete. +オンチェーンで登録された議題は、投票が完了するまでいくつかの州を経由する。 -- Pending: Status after the agenda is registered and until voting takes place. As the agenda is registered, the list of voters is determined. +- 保留：議題登録後、投票が行われるまでのステータス。 議題が登録されると、有権者のリストが決定される。 -- Active: Voting is in progress. The voting power of the voters gets fixed when voting begins. +- アクティブ投票中 有権者の投票権は投票開始時に固定される。 -- Passed: Agenda passed with the approval of a quorum. +- 可決：議事は定足数の承認により可決された。 -- Failed: Agenda rejected because it did not receive a quorum of approval votes. +- 不成立：議案は、賛成票の定足数に達しなかったため否決された。 -- Queued: Waiting period after the passing of the agenda and before the execution. +- 待ち時間：アジェンダ通過後、実行までの待ち時間。 -- Executed: Agenda fully executed. +- 実行されたアジェンダは完全に実行された。 ![](/img/misc/gov-process-2.png) -##### Enforceability +##### 強制力 -Kaia Blockchain is configurable via several network parameters, with which they can be altered by on-chain governance. An example of network parameters is “upperboundbasefee”, which defines the maximum value to which the dynamic gas fee can go up. There exists a system contract named GovParam, which enables the enforceability of the governance proposal. This contract is a key-value storage with an activation number for each key. A value of network parameter can be updated by submitting a tuple of (param as a key, new value, activation block number), which will be read by validators and be activated starting from the activation block. +カイア・ブロックチェーンは、いくつかのネットワーク・パラメーターによって設定可能であり、オンチェーン・ガバナンスによって変更することができる。 ネットワーク・パラメーターの例としては、"upperboundbasefee "がある。 GovParamというシステム契約が存在し、ガバナンス提案の強制力を可能にする。 この契約は、各キーにアクティベーション番号を持つキー・バリュー・ストレージである。 ネットワークパラメータの値は、(paramをキーとする, 新しい値, アクティブ化ブロック番号)のタプルを送信することで更新できる。 ![](/img/misc/enforceability.png) -The above figure shows how network parameters are updated via on-chain governance. A governance proposal can contain a transaction, which will be executed once the proposal passes. When proposing, the proposer attaches a transaction which invokes GovParam. When the proposal passes, the secretary sends a transaction to execute the proposal, which will internally invoke the transaction contained in the proposal. Validators check GovParam every block and apply the new network parameter value at the activation block. In this way, the network parameters can be enforced in a decentralized manner. +上図は、オンチェーン・ガバナンスによってネットワーク・パラメーターがどのように更新されるかを示している。 ガバナンス・プロポーザルにはトランザクションを含めることができ、そのトランザクションはプロポーザルが可決されると実行される。 提案するとき、提案者はGovParamを呼び出すトランザクションを添付する。 プロポーザルが通過すると、秘書はプロポーザルを実行するためのトランザクションを送信し、そのトランザクションは内部的にプロポーザルに含まれるトランザクションを呼び出す。 バリデータはブロックごとにGovParamをチェックし、アクティベーション・ブロックで新しいネットワーク・パラメータ値を適用します。 こうすることで、ネットワーク・パラメーターを分散型で実施することができる。 -### Kaia Evolution +### カイア・エボリューション -The Kaia Blockchain is committed to continuously adopting new technologies to achieve the three technical objectives introduced earlier. Some of these technologies are expected to be developed and implemented in the near future. Specifically, new technologies that Kaia blockchain will adopt can improve the aforementioned three goals; high performance permissionless allows anyone to become a node validator, mitigating the negative effect of MEV with transparent tx ordering, archiving old blocks in a verifiable manner, and public governance delegation can facilitate high performance, transparency, and sustainability. +カイア・ブロックチェーンは、先に紹介した3つの技術的目標を達成するために、継続的に新しい技術を採用することを約束する。 これらの技術のいくつかは、近い将来に開発・実用化される見込みである。 具体的には、Kaiaブロックチェーンが採用する新技術は、前述の3つの目標を改善することができる。高性能なパーミッションレスにより、誰でもノード検証者になることができ、透明なTX順序付けによりMEVの悪影響を緩和し、検証可能な方法で古いブロックをアーカイブし、パブリックガバナンスの委任により、高性能、透明性、持続可能性を促進することができる。 -#### High-Performance Permissionless +#### 高性能パーミッションレス -BFT-type consensus algorithms generally have restrictions in the process of participating as a validator. This is due to the tendency of the performance of the entire network to deteriorate caused by abnormal nodes when validators participate freely. As an integrated chain, Kaia pursues a completely permissionless network and will develop into a network where anyone can participate as a block creation node while maintaining high performance. After introducing the Permissionless Network, nodes meeting certain conditions will be given the role of block creation nodes. Specifically, an automated qualification verification process will be introduced to check whether the block creation node is qualified to maintain stability. In terms of consensus participating in the creation and verification of blocks, there are “candidates” and validators. In terms of governance, there are Governance Council Members. One can register as a candidate and meet specific conditions to become a validator. Validators can receive rewards by participating in the block creation consensus process. Permissionless Network is implemented through the following factors: +BFT型のコンセンサス・アルゴリズムには、一般に、バリデータとして参加する過程に制約がある。 これは、バリデータが自由に参加すると、異常ノードによってネットワーク全体の性能が低下しやすいためである。 統合されたチェーンとして、カイアは完全なパーミッションレスネットワークを追求し、高いパフォーマンスを維持しながら、誰もがブロック作成ノードとして参加できるネットワークへと発展していく。 パーミッションレス・ネットワーク導入後は、一定の条件を満たしたノードにブロック作成ノードの役割を与える。 具体的には、ブロック作成ノードが安定性を維持するために適格であるかどうかをチェックする自動適格性検証プロセスが導入される。 ブロックの作成と検証に参加するコンセンサスには、「候補者」と「検証者」がいる。 ガバナンスに関しては、ガバナンス評議会のメンバーがいる。 候補者として登録し、特定の条件を満たすことでバリデーターになることができる。 バリデーターはブロック生成のコンセンサスプロセスに参加することで報酬を受け取ることができる。 パーミッションレス・ネットワークは、以下の要素によって実現される： -- _**Unpredictable Proposer Selection Algorithm:**_ An algorithm that strengthens resistance to DoS attacks by changing the block proposer selection method difficult to predict. +- _**Unpredictable Proposer Selection Algorithm：**_ ブロック提案者の選択方法を予測困難なものに変更することで、DoS攻撃に対する耐性を強化するアルゴリズム。 -- _**VRank (Validator Reputation Evaluation Framework):**_ A framework that evaluates the reputation of a validator. +- \*\*\*VRank (Validator Reputation Evaluation Framework):\*\*\*バリデータの評価を行うフレームワーク。 -- _**Autonomous Validator Slashing System:**_ A system that penalizes erroneous or malicious actions of validators. +- _**Autonomous Validator Slashing System:**_ バリデータによる誤ったまたは悪意のある行動にペナルティを与えるシステム。 -- _**System Transaction and Consensus Msg:**_ A reflection of the latest consensus information in the contract for each block through a “system transaction” automatically generated by the block proposer. +- _**System Transaction and Consensus Msg:**_ ブロック提案者によって自動的に生成される「システムトランザクション」を通じて、各ブロックの契約における最新の合意情報の反映。 -#### Maximal Extraction Value +#### 最大抽出値 -MEV (Maximal Extractable Value) is the potential benefit that can be gained by strategically ordering or changing the transaction order in a block. MEV involves unfair practices, such as front-running, to gain profits at the expense of other users. Kaia Network aims to build a system that ensures a fair and transparent transaction order to mitigate the negative effects of MEV. Also, a method to redistribute or burn MEV extraction profits into the network ecosystem will be provided to support the sustainable development of the network. Lastly, a system to monitor and share transactions in real time will be implemented to prevent any unfair practices that may be carried out by validators, increasing the reliability of the network. This will not only increase the transparency and fairness of the Kaia network but will also greatly contribute to the sustainable development of the ecosystem. +MEV（Maximal Extractable Value）とは、ブロック内の取引順序を戦略的に変更することで得られる潜在的な利益のことである。 MEVは、他の利用者を犠牲にして利益を得るために、フロントランニングなどの不公正な慣行を伴う。 カイア・ネットワークは、MEVの弊害を軽減するため、公正で透明な取引秩序を確保するシステムの構築を目指している。 また、ネットワークの持続可能な発展をサポートするために、MEV抽出利益をネットワークの生態系に再分配または燃焼させる方法が提供される。 最後に、バリデーターによる不正行為を防止するため、取引をリアルタイムで監視・共有するシステムを導入し、ネットワークの信頼性を高める。 これは、カイア・ネットワークの透明性と公平性を高めるだけでなく、生態系の持続可能な発展にも大きく貢献するだろう。 -#### Block Data Archiving +#### ブロック・データ・アーカイブ -Blockchain continuously has an increase in the blocks (data) stored over time due to transaction history and execution of smart contracts. The capacity of Kaia Blockchain is growing even faster due to its short block time and high transaction throughput (TPS). As a result, the cost of new validators participating in the network and verifying the blocks by synchronizing them is also increasing. The volume of data accumulated over the years is not small, and it takes a lot of resources to verify it. High verification costs work as a barrier for new validators to enter, which can reduce the reliability of the chain. To solve this issue, Kaia Blockchain will study how to reduce the verification cost of past blocks. The following methods will be considered and introduced as they compress or archive old blocks in a verifiable manner so that only the archived data can be quickly verified without each block having to be verified. +ブロックチェーンは、取引履歴やスマートコントラクトの実行により、時間とともに保存されるブロック（データ）が増え続ける。 カイア・ブロックチェーンのキャパシティは、その短いブロックタイムと高いトランザクション・スループット（TPS）により、さらに急速に拡大している。 その結果、新たなバリデータがネットワークに参加し、ブロックを同期させて検証するコストも増大する。 長年にわたって蓄積されたデータの量は決して少なくなく、それを検証するには多くのリソースが必要だ。 高い検証コストは、新しいバリデーターが参入する際の障壁となり、チェーンの信頼性を低下させる。 この問題を解決するため、カイア・ブロックチェーンは過去のブロックの検証コストを削減する方法を研究する。 各ブロックを検証することなく、アーカイブされたデータのみを迅速に検証できるように、検証可能な方法で古いブロックを圧縮またはアーカイブする以下の方法を検討し、紹介する。 -- **Verifiable block data compression:** Compresses blocks in a verifiable manner. +- \*\*検証可能なブロックデータ圧縮：\*\*検証可能な方法でブロックを圧縮する。 - - Block data pruning at a certain block cycle or data unit + - あるブロック周期またはデータ単位でのブロックデータの刈り込み - - Convert the blocks pruned in on-chain into a verifiable certificate and record in on-chain. This certificate is compressed and recorded as a Commitment using cryptography (such as KZG) or Proof using the recursion method of ZKP. + - オンチェーンで刈り込まれたブロックを検証可能な証明書に変換し、オンチェーンに記録する。 この証明書は圧縮され、（KZGのような）暗号を使ったコミットメント、またはZKPの再帰法を使った証明として記録される。 - - Support a verification system that can verify certificates in on-chain + - オンチェーンで証明書を検証できる検証システムをサポートする。 - - Verification system efficiently and constantly verifies certificates. + - 検証システムは、効率的かつ継続的に証明書を検証する。 - - At the time of compression, the certificate is verified and recorded in the block when the next block is created. + - 圧縮時に証明書が検証され、次のブロックが作成されるときにブロックに記録される。 - - Anyone can verify the corresponding certificate through a verification system. + - 誰でも検証システムを通じて対応する証明書を検証することができる。 -- **Lightweight block synchronization:** When participating as a new node or verifier, synchronize and verify the compressed certificates and subsequent blocks rather than synchronize the entire block data. +- \*\*新しいノードまたは検証者として参加する場合、ブロックデータ全体を同期するのではなく、圧縮された証明書とそれに続くブロックを同期して検証する。 -- **Support DA Layer:** Some users and dApps require a checkup on historical data. A DA Layer is provided to provide trusted data without faults. +- **サポートDAレイヤー:** 一部のユーザーやdAppsは、履歴データのチェックを必要とする。 DAレイヤーは、故障のない信頼できるデータを提供するために提供される。 -By dramatically reducing the verification cost by the above methods, new validators will be able to onboard quickly. +上記の方法によって検証コストを劇的に削減することで、新しいバリデーターは迅速に乗り込むことができる。 -#### Public Delegation +#### 公的代表団 -Kaia Blockchain provides a function where validator operators can be delegated. To provide this function as a default, Kaia Blockchain will additionally develop and provide a contract providing a public delegation function in conjunction with staking contracts for validators. This will allow users to participate in governance in the future by expanding the voting power of voters by delegating tokens to other voters expressing opinions on their behalf. This structure is similar to representative democracy, a form of politics in which the people elect members of the National Assembly, and the members of the National Assembly vote when the National Assembly passes an agenda. The users, furthermore, can delegate or revoke their delegation whenever they wish in Kaia Blockchain. This will allow general holders to reflect their opinions in governance and a governance system respecting diverse opinions will be established. +カイア・ブロックチェーンは、バリデータのオペレータを委譲できる機能を提供している。 この機能をデフォルトとして提供するために、カイアブロックチェーンはさらに、バリデータのステーキング契約と連動して、パブリック委任機能を提供する契約を開発し、提供する。 これによってユーザーは、自分の代わりに意見を表明する他の有権者にトークンを委譲することで、有権者の投票力を拡大し、将来的に統治に参加できるようになる。 この構造は、国民が国会議員を選出し、国会が議案を可決する際に国会議員が投票する政治形態である代議制民主主義に似ている。 ユーザーはさらに、カイア・ブロックチェーンでいつでも好きなときに委任したり、委任を取り消したりすることができる。 これにより、一般株主の意見をガバナンスに反映させ、多様な意見を尊重するガバナンス体制を構築する。 -## Roadmap +## ロードマップ -Kaia Blockchain is an integrated mainnet platform that started with the integration of the Finschia Foundation and the Klaytn Foundation. Its core goal is to provide an infrastructure for the adoption of Web3. To achieve this goal, Kaia Blockchain seeks to facilitate the development of blockchain-based projects through builder-centric support. Through this, new potentials of Web3 technology will be explored. Kaia Blockchain provides developers with essential toolkits, SDKs, and IDEs to help them easily implement innovative and competitive solutions at all stages of project development. +Kaiaブロックチェーンは、Finschia財団とKlaytn財団の統合から始まった統合メインネットプラットフォームである。 その中心的な目標は、Web3を採用するためのインフラを提供することである。 この目標を達成するため、カイア・ブロックチェーンは、ビルダー中心のサポートを通じて、ブロックチェーン・ベースのプロジェクトの開発を促進しようとしている。 これを通じて、Web3技術の新たな可能性を探る。 カイア・ブロックチェーンは、開発者がプロジェクト開発のあらゆる段階で革新的で競争力のあるソリューションを容易に実装できるよう、必要不可欠なツールキット、SDK、IDEを提供します。 -In addition, strategies such as messenger integration through cooperation with Kakao and LINE will help Web2 users easily transfer to Web3. This approach will accelerate the adoption of Web3 technology and allow more users to experience the benefits of blockchain technology. Kaia Blockchain will foster the growth of a strong developer community and explore new possibilities in blockchain technology by enabling access to various infrastructure assets and KAIA funds while also supporting decentralized governance and permissionless participation. +さらに、カカオやLINEとの協力によるメッセンジャー統合などの戦略は、Web2ユーザーがWeb3に簡単に移行できるようにする。 このアプローチは、Web3技術の採用を加速し、より多くのユーザーがブロックチェーン技術の利点を体験できるようにする。 カイア・ブロックチェーンは、強力な開発者コミュニティの成長を促進し、様々なインフラ資産やKAIAファンドへのアクセスを可能にすることで、ブロックチェーン技術の新たな可能性を追求すると同時に、分散型ガバナンスと無許可参加をサポートする。 -The roadmap of the integrated mainnet focuses on supporting developers and driving Web3 adoption at the same time. This will enable Kaia Blockchain to help both developers and general users build successful projects, adopt blockchain technology more broadly, and establish a solid foundation to explore the new possibilities of the Web3 world. +統合メインネットのロードマップは、開発者のサポートとWeb3の普及を同時に推進することに重点を置いている。 これにより、カイア・ブロックチェーンは、開発者と一般ユーザーの両方がプロジェクトを成功させ、ブロックチェーン技術をより広く採用し、Web3の世界の新たな可能性を探求するための強固な基盤を確立することができる。 -### Short-term Initiatives +### 短期的な取り組み #### 2024 Q1 -- Construction and operation of the Klaytn & Finschia integrated TF +- クレイトン＆フィンシャ統合TFの建設と運営 #### 2024 Q2 -- Establishment of a new integrated chain brand -- Establishment of a joint marketing system and community integration -- Preparation for ecosystem infrastructure, DApp, and service migration (~Q4) -- Network support for integration and response to existing DApps and services (~Q4) -- Preparation for new integrated tokens issuance and swap service provision -- Establishment of the 1st integrated network (EVM) +- 新しい統合チェーン・ブランドの確立 +- 共同販売システムの確立と地域社会の統合 +- エコシステム・インフラ、DApp、サービス移行の準備（～第4四半期） +- 既存のDAppsやサービスとの統合や対応のためのネットワークサポート（～第4四半期） +- 新統合トークン発行とスワップサービス提供の準備 +- 第1統合ネットワーク（EVM）の構築 #### 2024 Q3 -- Issuance of new integrated tokens and provision of swap services -- Strengthening of the node user/community delegation function -- Introduction of a new burning model (~Q4) +- 新統合トークンの発行とスワップサービスの提供 +- ノードのユーザー／コミュニティ委任機能の強化 +- 新燃焼モデルの導入（～第4四半期） #### 2024 Q4 -- Reorganization of the integrated foundation and promotion of joint business initiatives -- Establishment of the 2nd integrated network +- 統合基盤の再編と共同事業の推進 +- 第2統合ネットワークの構築 -### Long-term Initiatives +### 長期的な取り組み -#### Establishment of infrastructure for institutional needs +#### 制度的ニーズに対応するインフラの確立 -- Establishment of integrated token, Fiat On/Off Ramp, for major Asian countries -- Establishment of infrastructure for improved accessibility by institutional investors +- アジア主要国向け統合トークン「フィアット・オン／オフ・ランプ」の設立 +- 機関投資家のアクセス向上のためのインフラ整備 -#### Strengthening of large-scale DeFi infrastructure +#### 大規模DeFiインフラの強化 -- Establishment of a new De-fi ecosystem for the integrated mainnet -- Expansion of RWA (Real World Asset) linked services +- 統合メインネットのための新しいDe-fiエコシステムの確立 +- RWA（リアル・ワールド・アセット）連動サービスの拡大 -#### Launching of native stablecoins +#### ネイティブ安定コインのローンチ -- Launching of key stable coins based on the integrated mainnet -- Expansion of native stable coin-based services +- 統合メインネットに基づく主要安定コインのローンチ +- 安定したコインベースのネイティブ・サービスの拡大 -#### Asian community boost-up +#### アジア・コミュニティーの強化 -- Re-establishment of developer and user communities in each Asian country -- Expansion of governance and ecosystem partners in major countries +- アジア各国における開発者・ユーザーコミュニティの再構築 +- 主要国におけるガバナンスとエコシステム・パートナーの拡大 -#### Discovery of AI DApp categories +#### AI DAppカテゴリーの発見 -- Establishment of new AI DApp categories and activation of onboarding -- Discovery of generative AI-based content/avatar/game Dapps +- 新しいAI DAppカテゴリーの確立とオンボーディングの活性化 +- ジェネレーティブなAIベースのコンテンツ／アバター／ゲームDappsの発見 -#### Large-scale on-chain tokenization of Web2 assets +#### Web2資産の大規模なオンチェーン・トークナイゼーション -- Linking of Web2 digital items, memberships, and ticket markets -- Discovery of large-scale item tokenization and mass adoption cases +- Web2デジタルアイテム、メンバーシップ、チケット市場のリンク +- 大規模なアイテム・トークナイゼーションと大量導入事例の発見 -#### Onboarding of Asian SSS game companies +#### アジアのSSSゲーム会社のオンボーディング -- Interoperable game onboarding based on Brown Friends IP -- Web3 game onboarding based on Japanese SSS-rated game company IP +- ブラウン・フレンズIPに基づく相互運用可能なゲーム・オンボーディング +- 日本のSSS級ゲーム会社IPをベースにしたWeb3ゲームオンボーディング -#### Cooperation in Global IP projects +#### グローバルIPプロジェクトへの協力 -- Web3 project onboarding of large global IP companies -- Strengthening of onboarding infrastructure for Web2 companies +- 大手グローバルIP企業のWeb3プロジェクトオンボーディング +- Web2企業向けオンボーディング・インフラの強化 -## Important Notes +## 重要な注意事項 -### Disclaimer of liability +### 免責事項 -To the maximum extent permitted by the applicable laws, regulations and rules, the Kaia Foundation shall not be liable for any indirect, special, incidental, consequential or other losses of any kind, in tort, contract or otherwise (including but not limited to loss of revenue, income or profits, and loss of use or data), arising out of or in connection with any acceptance of or reliance on this Whitepaper or any part thereof by you. +適用される法律、規制、規則により許される最大限の範囲において、カイア財団は、不法行為、契約、その他のいかなる種類の間接的、特別、偶発的、結果的、またはその他の損失（収入、所得、利益の損失、使用またはデータの損失を含むがこれらに限定されない）についても、利用者による本ホワイトペーパーまたはその一部の受諾または信頼に起因または関連して生じる一切の責任を負わないものとします。 -### No representations and warranties +### いかなる表明および保証も行わない -The Kaia Foundation does not make or purport to make, and hereby disclaims, any representation, warranty or undertaking in any form whatsoever to any entity or person, including any representation, warranty or undertaking in relation to the truth, accuracy and completeness of any of the information set out in this Whitepaper. +カイア財団は、本ホワイトペーパーに記載されている情報の真実性、正確性、完全性に関するいかなる表明、保証、約束も含め、いかなる団体または個人に対しても、いかなる形式の表明、保証、約束も行わず、また行うことを意図せず、ここに否認します。 -Nothing contained in this Whitepaper is or may be relied upon as a promise, representation or undertaking as to the future performance or policies of the Kaia Foundation. All information, features, issuances, distributions, and architectures are subject to change at any time, at the sole and absolute discretion of Foundation and/or Kaia Governance depending on the then current roadmap presented in this Whitepaper. +本ホワイトペーパーに含まれるいかなる内容も、カイア財団の将来の業績や方針に関する約束、表明、約束として依拠されるものではなく、また依拠することもできません。 すべての情報、機能、発行、ディストリビューション、およびアーキテクチャは、本ホワイトペーパーに示されたその時点でのロードマップに基づき、Foundationおよび/またはKaia Governanceの単独かつ絶対的な裁量で、いつでも変更される可能性があります。 -Further, the Kaia Foundation disclaims any responsibility to update any forward-looking statements or publicly announce any revisions to those forward-looking statements to reflect future developments, events or circumstances, even if new information becomes available or other events occur in the future. +さらに、カイア財団は、将来において新たな情報が入手可能になったり、その他の事象が発生したりしたとしても、将来の展開、事象、状況を反映するために、将来見通しに関する記述を更新したり、将来見通しに関する記述の修正を公表したりする責任を一切負いません。 -Please note that this Whitepaper is also only a work in progress and the information in this Whitepaper is current only as of the date on the cover hereof. The Kaia Foundation reserves the right to update the Whitepaper from time to time. +本ホワイトペーパーはあくまでも作成途中のものであり、本ホワイトペーパーに記載されている情報は、本ホワイトペーパーの表紙に記載されている日付現在のものであることにご留意ください。 カイア財団は、ホワイトペーパーを随時更新する権利を有します。 -### Staking services +### 杭打ちサービス -If you choose to participate in the KAIA staking programme, any such service provided to you may be facilitated by the Kaia Foundation acting as a transaction validator on the Kaia and providing its private nodes for staking on your behalf. Any applicable Delegation Rewards will be determined by the protocols of the Kaia and will be credited . +あなたがKAIAステーキングプログラムに参加することを選択した場合、あなたに提供されるそのようなサービスは、カイア財団がカイア上でトランザクションバリデータとして機能し、あなたに代わってステーキングのためにプライベートノードを提供することによって促進される場合があります。 適用されるデレゲーションリワードは、カイアのプロトコルによって決定され、. -You acknowledge and understand that the Kaia Foundation does not guarantee that you will receive any Delegation Rewards and such staking services do not constitute a fixed deposit product or issuance of securities, which would fall under the regulatory scope of the FSMR. +利用者は、カイア財団が、利用者が委任報酬を受け取ることを保証するものではなく、かかるステーキングサービスは、FSMRの規制範囲に該当する定期預金商品または有価証券の発行に該当しないことを認識し、理解するものとします。 -Withdrawal of staked assets may be delayed as a result of protocol unstaking periods or network conditions, and the Kaia Foundation cannot guarantee the timing and amount of the distribution of the Network Contribution Rewards. The Kaia Mainnet and relevant interfaces used for the delivery of KAIA staking services have inherent risks and the market for KAIA tokens and rewards may be highly volatile due to factors that include but are not limited to adoption, speculation, technology, security, and regulations. You agree and acknowledge that the Kaia Foundation is not responsible or liable for any of these variables or risks. +ステークされた資産の引き出しは、プロトコルのアンステーク期間またはネットワーク状況の結果として遅れる可能性があり、カイア財団はネットワーク貢献報酬の分配のタイミングと金額を保証することはできません。 KAIAメインネットおよびKAIAステーキング・サービスを提供するために使用される関連インターフェースには固有のリスクがあり、KAIAトークンおよび報酬の市場は、採用、投機、技術、セキュリティ、規制を含むがこれらに限定されない要因により、非常に不安定になる可能性があります。 利用者は、カイア財団がこれらの変数またはリスクに対していかなる責任も負わないことに同意し、これを認めます。 -### No advice +### アドバイスなし -No information in this Whitepaper should be considered to be business, legal, financial or tax advice regarding the Kaia Foundation or KAIA. You should consult your own legal, financial, tax or other professional adviser regarding the Kaia Foundation and their businesses and operations, and KAIA. You should be aware that you may be required to bear the financial risk of any purchase of KAIA for an indefinite period of time. +本ホワイトペーパーに記載されているいかなる情報も、カイア財団またはKAIAに関するビジネス、法律、財務、税務上のアドバイスとみなされるべきではありません。 カイア財団とその事業、運営、KAIAに関しては、ご自身の法律、財務、税務、その他の専門アドバイザーにご相談ください。 あなたは、KAIAのいかなる購入についても、不特定期間にわたって財務的リスクを負担することが求められる可能性があることを認識すべきです。 -### Restrictions on distribution and dissemination +### 配布と普及の制限 -The distribution or dissemination of this Whitepaper or any part thereof may be prohibited or restricted by the laws, regulatory requirements and rules of any jurisdiction. In the case where any restriction applies, you are to inform yourself about, and to observe, any restrictions which are applicable to your possession of this Whitepaper or such part thereof (as the case may be) at your own expense and without liability to the Kaia Foundation. Persons who have been provided access to this Whitepaper or to whom a copy of this Whitepaper has been distributed or disseminated or who otherwise have the Whitepaper in their possession shall not circulate it to any other persons, reproduce or otherwise distribute this Whitepaper or any information contained herein for any purpose whatsoever nor permit or cause the same to occur. +本ホワイトペーパーまたはその一部の配布または普及は、法域の法律、規制要件および規則により禁止または制限されている場合があります。 何らかの制限が適用される場合、利用者は本ホワイトペーパーまたはその一部（場合によって）の所有に適用される制限について自ら知り、それを遵守するものとします。 本ホワイトペーパーへのアクセスを提供された者、本ホワイトペーパーのコピーが配布もしくは流布された者、またはその他の方法で本ホワイトペーパーを所有する者は、いかなる目的であれ、本ホワイトペーパーを他の者に配布したり、本ホワイトペーパーまたは本ホワイトペーパーに含まれる情報を複製したり、その他の方法で配布したりしてはならず、またそのようなことを許可したり、させたりしてはならない。 -### Risks and uncertainties +### リスクと不確実性 -Prospective purchasers of KAIA should carefully consider and evaluate all risks and uncertainties associated with the Kaia Foundation, and its businesses and operations, and all information set out in this Whitepaper and the T&Cs, prior to any purchase of KAIA. +KAIAの購入希望者は、KAIAの購入に先立ち、カイア財団、その事業と運営に関連するすべてのリスクと不確実性、および本ホワイトペーパーとT&Cに記載されたすべての情報を慎重に検討し、評価する必要があります。 -You should not transact in KAIA if you are not familiar with digital tokens of this nature. Transacting in digital tokens may not be suitable for you if you are not familiar with the technology in which KAIA services will be provided. +このような性質のデジタルトークンに精通していない場合は、KAIAでの取引を行うべきではありません。 KAIAサービスが提供される技術に精通していない場合、デジタルトークンでの取引は適していないかもしれません。 -You should be aware that the value of KAIA may fluctuate greatly. You should buy KAIA only if you are prepared to accept the risk of losing all the money you put into KAIA. +KAIAの価値は大きく変動する可能性があることをご承知おきください。 KAIAを購入するのは、KAIAに投入した資金をすべて失うリスクを受け入れる覚悟がある場合に限るべきである。 -As previously indicated, participating dApps will receive allocations of KAIA from the Foundation that are to be distributed to dApp users. Subject to dApp’s respective distribution policies, dApps may from time to time, either directly or indirectly, make large distributions of KAIA to users, which could have the effect of increasing the overall supply of KAIA that is traded on relevant trading platforms. It is possible that such distributions could have a negative impact on the market price of KAIA, particularly if a large number of recipients of KAIA engage in sales of KAIA on relevant trading platforms in a short period of time. Please note that a specific way of each dApp’s distributions of KAIA may vary depending upon each dApp’s jurisdiction or country of registration to fully comply with applicable regulations. +前述の通り、参加dAppは財団からKAIAの割り当てを受け、dAppユーザーに配布される。 dAppの各配布ポリシーに従い、dAppは直接的または間接的にKAIAをユーザーに大量に配布することがあり、その結果、関連する取引プラットフォームで取引されるKAIAの全体的な供給量が増加する可能性があります。 このような分配がKAIAの市場価格にマイナスの影響を与える可能性があり、特にKAIAの受け手が短期間に関連取引プラットフォームでKAIAの売却を多数行った場合、KAIAの市場価格にマイナスの影響を与える可能性がある。 各dAppのKAIAの具体的な配布方法は、適用される規制に完全に準拠するため、各dAppの管轄区域または登録国によって異なる場合があることにご注意ください。 -### KAIA issuance costs +### KAIA発行費用 -The Kaia Foundation will, in any event, incur no costs in regard to any issuance or distribution of KAIA. +カイア財団は、いかなる場合においても、KAIAの発行または配布に関していかなる費用も負担しません。 -**THERE IS NO GUARANTEE THAT THE FUNCTIONALITIES OF KAIA, OR THAT THE KAIA TOKEN ECONOMY INFRASTRUCTURE, WILL BE DELIVERED OR REALISED. IF ANY OF SUCH RISKS AND UNCERTAINTIES DEVELOPS INTO ACTUAL EVENTS, THE BUSINESS, FINANCIAL CONDITION, RESULTS OF OPERATIONS AND PROSPECTS OF THE KAIA FOUNDATION COULD BE MATERIALLY AND ADVERSELY AFFECTED. IN SUCH CASES, YOU MAY LOSE ALL OR PART OF THE VALUE OF KAIA. IN THE EVENT THAT YOU HAVE PURCHASED KAIA, YOUR PURCHASE CANNOT BE REFUNDED OR EXCHANGED.** +\*\*kaiaの機能、またはkaiaトークンエコノミーのインフラが提供され、実現されることを保証するものではありません。 このようなリスクと不確実性のいずれかが実際の事象に発展した場合、カイア財団の事業、財務状況、経営成績、見通しに重大かつ不利な影響が及ぶ可能性があります。 このような場合、お客様はKaiaの価値の全部または一部を失う可能性があります。 カイアを購入された場合、返金や交換はできません。 -**IF YOU ARE IN ANY DOUBT AS TO THE ACTION YOU SHOULD TAKE, YOU SHOULD CONSULT YOUR LEGAL, FINANCIAL, TAX OR OTHER PROFESSIONAL ADVISOR(S).** +\*\*取るべき行動について疑問がある場合は、法律、財務、税務、その他の専門アドバイザーに相談してください。 + +## 導言 + +在本指南中，我們將指導您使用 [Kaia Hardhat Utils](https://github.com/ayo-klaytn/hardhat-utils) 在專用 Kaia 網絡上部署 Greeter 合同。 通過本指南，您將學會如何 + +- 設立 "硬頭巾 "項目。 +- 啟動一個模擬啟明星測試網的專用網絡。 +- 利用 Hardhat 工具在該私有網絡上部署智能合約。 + +## 先決條件 + +學習本教程的前提條件如下： + +- 代碼編輯器：源代碼編輯器，如 [VS Code](https://code.visualstudio.com/download)。 +- Docker：如果您沒有安裝 docker，請使用此 [鏈接](https://docs.docker.com/desktop/) 進行安裝。 +- [Node.js 和 npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)：Node 18 及以上版本。 + +## 設置開發環境 + +在本節中，我們將安裝 hardhat、Kaia hardhat utils 和引導項目所需的其他必要依賴項。 + +**第 1 步：創建項目目錄** + +```js +mkdir $HOME/kaia-greeter +cd kaia-greeter +``` + +**第 2 步：初始化 npm 項目** + +```js +npm init -y +``` + +**第 3 步：安裝 hardhat、hardhat-utils 和其他依賴項** + +- 在終端中複製並粘貼以下代碼，安裝 hardhat 和 hardhat-utils + +```js +npm i hardhat @klaytn/hardhat-utils +``` + +- 複製並粘貼以下代碼以安裝其他依賴項 + +```js +npm install @nomiclabs/hardhat-ethers hardhat-deploy dotenv +``` + +:::note + +hardhat-utils 插件依賴於 [hardhat-ethers](https://www.npmjs.com/package/@nomiclabs/hardhat-ethers) 和 [hardhat-deploy](https://www.npmjs.com/package/hardhat-deploy) 插件。 確保在`hardhat.config.js`或`hardhat.config.ts`中要求或導入它們。 + +::: + +:::info + +(建議）安裝硬帽速記裝置。 但您仍然可以使用 npx 硬頭盔執行任務。 + +```js +npm install hardhat-shorthand --save +``` + +::: + +**第 4 步：初始化硬頭盔項目** + +運行以下命令啟動硬頭盔項目： + +```js +npx 硬頭盔啟動 +``` + +在本指南中，你將選擇 "創建一個空的 hardhat.config.js "項目，如下圖所示： + +```js +888 888 888 888 +888 888 888 888 +888 888 888 888 888b. 888d888 .d88888 88888b. 8888b. 888888 +888888 "88b 888P" d88" 888888 "88b "88b 888 +888888 .d88888 888888 .d88888 888888 +888888 888888 Y88b. +888 888 "Y888888 888 "Y88888 888 "Y888888 "Y888 +👷 歡迎訪問 Hardhat v2.22.9 👷‍ +?您要做什麼？ … + 創建一個 JavaScript 項目 + 創建一個 TypeScript 項目 + 創建一個 TypeScript 項目（使用 Viem） +👷 創建一個空的 hardhat.config.js + 退出 +``` + +**第 5 步：創建 .env 文件** + +現在在項目文件夾中創建 `.env` 文件。 該文件可幫助我們將環境變量從 `.env` 文件加載到 process.env 文件中。 + +在終端中複製並粘貼此命令，創建一個 `.env` 文件 + +```js +touch .env +``` + +配置您的 .env 文件如下： + +``` +private_key="複製並粘貼本地專用網絡提供的任意私人密鑰" +``` + +:::note + +在下一節啟動專用網絡時，就可以訪問本地網絡提供的私鑰。 + +::: + +**第 6 步：設置硬頭盔配置** + +用以下配置修改 `hardhat.config.js`： + +```js +require("@nomiclabs/hardhat-ethers"); +require("hardhat-deploy"); +require("@klaytn/hardhat-utils"); +require('dotenv').config() + +const accounts = [ + process.env.PRIVATE_KEY +]; + +/** @type import('hardhat/config').HardhatUserConfig */ +module.exports = { + solidity: "0.8.24", + networks: { + localhost: { + url: process.env.RPC_URL || "http://localhost:8545", + accounts: accounts, + }, + kairos: { + url: process.env.RPC_URL || "https://public-en-kairos.node.kaia.io", + accounts: accounts, + }, + kaia: { + url: process.env.RPC_URL || "https://public-en.node.kaia.io", + accounts: accounts, + } + }, + namedAccounts: { + deployer: { + default: 0, // here this will by default take the first account as deployer + }, + }, +}; +``` + +## 啟動專用網絡 + +為了啟動專用網絡，hardhat utils 插件為我們提供了一項任務，即輕鬆啟動專用網絡： + +```js +hh klaytn-node +``` + +![](/img/build/smart-contracts/pn-run-node.png) + +## 連接控制檯 + +專用網絡自帶 JavaScript 控制檯。 通過控制檯命令行，您可以向網絡發起部分 Kaia API 調用。 要附加到 JavaScript 控制檯，請執行以下命令： + +```js +hh klaytn-node --attach +``` + +```jsx title="Result Result " +Welcome to the Kaia JavaScript console! + instance: Klaytn/v0.9.2/linux-amd64/go1.22.1 + datadir: /klaytn + modules: admin:1.0 debug:1.0 eth:1.0 governance:1.0 istanbul:1.0 kaia:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0 +``` + +:::note + +輸入 **kaia** 或 **personal** 可獲得可用功能列表。 + +::: + +## 查看賬戶餘額 + +當我們啟動私人網絡時，它為我們提供了賬戶列表、私人密鑰和每個賬戶的預資助值。 + +要查看賬戶餘額，請執行以下命令。 + +```js +kaia.getBalance("0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266") +``` + +![](/img/build/smart-contracts/pn-check-balance.png) + +## 配置硬帽網絡環境 + +現在我們正在運行一個獨立的本地網絡，外部客戶端（錢包、dApp）可以連接到該網絡，我們需要通過運行此命令配置 hardhat 以使用該網絡： + +```js +export HARDHAT_NETWORK=localhost +hh accounts +``` + +```js +hh --network localhost 賬戶 +``` + +![](/img/build/smart-contracts/pn-lh-accounts.png) + +## 創建 KaiaGreeter 智能合約 + +在本節中，您將創建一個 KaiaGreeter 智能合約。 + +**步驟 1：** 在資源管理器窗格中新建一個名為 "**合同**"的文件夾，單擊 "新建文件 "按鈕並新建一個名為 "KaiaGreeter.sol "的文件。 + +**第 2 步：** 打開文件並粘貼以下代碼： + +```js +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.0; +import "hardhat/console.sol"; +contract KaiaGreeter { + uint256 totalGreetings; + constructor() { + console.log("Yo yo, Welcome to Kaia"); + } + function greet() public { + totalGreetings += 1; + console.log(msg.sender, "says hello kaia!"); + } + function getTotalGreetings() public view returns (uint256) { + console.log("We have %d total waves!", totalGreetings); + return totalGreetings; + } +} +``` + +## 部署 KaiaGreeter + +在本節中，我們將使用 hardhat-deploy 插件來部署我們的合同。 + +**步驟 1：** 在資源管理器窗格中，新建一個名為**deploy**的文件夾，然後單擊 "新建文件 "按鈕，創建一個名為 "deploy.js "的新文件。 + +**第 2 步：** 將以下代碼複製並粘貼到文件中。 + +```js +module.exports = async ({getNamedAccounts, deployments}) => { + const {deploy} = deployments; + const {deployer} = await getNamedAccounts(); + await deploy('KaiaGreeter', { + from: deployer, + args: [], + log: true, + }); +}; +module.exports.tags = ['KaiaGreeter']; +``` + +**步驟 3：** 在終端運行以下命令，告訴 Hardhat 在專用網絡上部署你的 KaiaGreeter 合同。 + +```js +hh 部署 +``` + +![](/img/build/smart-contracts/pn-deployed-tx.png) + +## 使用區塊資源管理器驗證交易 + +**步驟 1：** 要使用本地 blockscout 瀏覽器驗證我們的交易，請在新終端中運行以下命令： + +```js +hh explorer --network localhost +``` + +```js +[+] 使用 env： { + DOCKER_RPC_HTTP_URL：'http://host.docker.internal:8545/', + DOCKER_LISTEN: '0.0.0.0:4000', + DOCKER_DISABLE_TRACER: 'false', + DOCKER_DEBUG: '0' +} +[+] 在瀏覽器中打開：http://localhost：4000 + 網絡 blockscout_default 創建 + 網絡 blockscout_default 創建 + 容器 blockscout-db-1 創建 + 容器 blockscout-frontend-1 創建 + 容器 blockscout-smart-contract-verifier-1 創建 + 容器 blockscout-創建 + Container blockscout-smart-contract-verifier-1 創建 + Container blockscout-db-1 創建 + Container blockscout-frontend-1 創建 + Container blockscout-redis_db-1 創建 + Container blockscout-backend-1 創建 + Container blockscout-backend-1 創建 + Container blockscout-frontend-1 Starting + Container blockscout-redis_db-1 Starting + Container blockscout-smart-contract-verifier-1 Starting + Container blockscout-db-1 Starting + Container blockscout-db-1 Started + Container blockscout-redis_db-1 Started + Container blockscout-smart-contract-verifier-1 Started + Container blockscout-backend-1 Started + Container blockscout-frontend-1 Started + Container blockscout-backend-1 Started +``` + +**第 2 步：** 要訪問這個區塊資源管理器，請在瀏覽器中打開 [http://localhost:4000](http://localhost:4000)。 + +第 3 步：在搜索欄中複製並粘貼已部署的合同地址，然後按 Enter 鍵。 您應該能看到最近部署的合同。 + +![](/img/build/smart-contracts/pn-verify-tx-block-explorer.png) + +## 與已部署的合同互動 + +### 使用硬頭盔工具合同任務 + +1. 要調用已部署合約的只讀函數，請運行下面的命令： + +```js +hh 調用 KaiaGreeter getTotalGreetings +``` + +![](/img/build/smart-contracts/pn-read-function.png) + +2. 要向已部署的合約發送函數調用事務，請運行下面的命令： + +```js +hh 發送 KaiaGreeter 問候 +``` + +```jsx title="Result Result " +發送 KaiaGreeter#greet（tx：0xc0bd25ffb594c13d5ae1f77f7eb02f2978013c69f9f6e22694b76fa26c329e85）...ok（數據塊 2837，已用氣體：47457） +``` + +### 使用 Kaia SDK + +**步驟 1：** 要使用 [Kaia SDK](https://github.com/kaiachain/kaia-sdk) 與已部署的合約進行交互，需要運行此命令安裝 Kaia SDK： + +```js +npm install --save @kaiachain/ethers-ext +``` + +**步驟 2：** 在資源管理器窗格中，新建一個名為 "utils "的文件夾，然後單擊 "新建文件 "按鈕，在 utils 文件夾中新建一個名為 `kaia-sdk.js` 的文件。 + +第 3 步：將以下代碼複製並粘貼到文件中。 + +```js +const { JsonRpcProvider, Wallet } = require("@kaiachain/ethers-ext"); +const { ethers } = require("ethers"); +require('dotenv').config() + +const provider = new JsonRpcProvider("http://127.0.0.1:8545/") + +const privKey = process.env.PRIVATE_KEY; +const signer = new ethers.Wallet(privKey, provider); +const contractAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3" // PASTE DEPLOYED CONTRACT ADDRESS; + +const KaiaGreeterABI = require("../artifacts/contracts/KaiaGreeter.sol/KaiaGreeter.json").abi; + +async function getCode(ca) { + const tx = await provider.getCode(ca); + console.log(tx); +} + +async function greet(ca) { + const klaytnGreeter = new ethers.Contract(ca, KaiaGreeterABI, signer); + const tx = await klaytnGreeter.greet(); + console.log( tx); +} + +async function getTotalGreetings(ca) { + const klaytnGreeter = new ethers.Contract(ca, KaiaGreeterABI, provider); + const value = await klaytnGreeter.getTotalGreetings(); + console.log(value.toString()); +} + +// getCode(contractAddress); +getTotalGreetings(contractAddress); +// greet(contractAddress); +``` + +**步驟 4：** 要執行本文件中聲明的任何函數，請確保像執行 getTotalGreetings() 函數那樣取消註釋，然後在終端運行以下命令。 + +```js +node utils/kaia-sdk.js +``` + +![](/img/build/smart-contracts/pn-run-kaia-sdk.png) + +有關 hardhat-utils 的更深入指南，請參閱 [hardhat-utils github](https://github.com/ayo-klaytn/hardhat-utils)。 此外，您還可以在 [GitHub](https://github.com/ayo-klaytn/kaia-hardhat-utils-example) 上找到本指南的完整代碼實現。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md new file mode 100644 index 000000000000..5275f5ebf80d --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/deploy/thirdweb.md @@ -0,0 +1,169 @@ +# 使用 Thirdweb 部署智能合約 + +![](/img/banners/kaia-thirdweb.png) + +## 導言 + +本節將指導您使用 [ThirdWeb](https://portal.thirdweb.com/)，在 Kaia Network 上部署 Marketplace 合同和相應的 NFT 收集合同。 Thirdweb 是一個完整的 Web3 開發框架，可為您提供將應用程序和遊戲連接到去中心化網絡所需的一切。 + +市場合約允許用戶列出 NFT 進行直接銷售或拍賣，從而加強了 NFT 的買賣，就像在 OpenSea 上所做的那樣。 + +完成本指南後，您將能夠 + +- 使用 thirdweb 創建和定製合同。 +- 使用 thirdweb 對智能合約進行編譯、部署和交互。 + +## 入門 + +在本文中，我們將探討使用 thirdweb 創建、自定義和部署合同的不同方法，即 + +- 使用第三網絡儀錶板 +- 使用 thirdweb CLI + +在本指南中，我們將演示如何使用 thirdweb 控制面板部署 MarketPlace 合同，並使用 thirdweb CLI 部署相應的 nft 集合，以便在市場上列出。 + +> 注：我們將不解釋市場合約的機制，因為我們的重點是探索用於創建、部署和與智能合約交互的 thirdweb 面板和 CLI。 + +## 使用 thirdweb 儀錶板創建和部署市場合同 + +在本節中，我們將使用 thirdweb 面板創建並部署市場合同。 為此，請按照以下步驟操作： + +1. 前往 [thirdweb dashboard](https://thirdweb.com/dashboard?ref=blog.thirdweb.com)，從合同列表中選擇 **MarketPlace** 合同。 + +![](/img/build/get-started/marketplace-explore.png) + +2. 在合同概覽儀錶板中單擊**立即部署**。 + +![](/img/build/get-started/marketplace-deploy.png) + +3. 配置市場合同，使其包含以下參數：市場的**名稱**、**描述**和**圖像**。 + +![](/img/build/get-started/marketplace-contract-details.png) + +4. 點擊 **立即部署**，如上圖所示，然後等待交易完成。 + +![](/img/build/get-started/marketplace-deployed.png) + +交易成功執行後，您可以在 [Kaiascope](https://kaiascope.com/)的搜索欄中粘貼合同地址，以驗證您的部署。 + +## 使用 thirdweb CLI 創建和部署 NFT 收集合同 + +在本節中，我們將使用 [thirdweb CLI](https://portal.thirdweb.com/cli?ref=blog.thirdweb.com)創建和部署將在 Marketplace 中列出的 NFT 程序集。 為此，請按照以下步驟操作： + +### 創建合同 + +1. 在終端中運行此命令來創建合同： + +```bash +npx thirdweb create --contract +``` + +2. 輸入您喜歡的命令行提示值： + + i. 為項目命名 + + ii. 選擇您喜歡的框架：**Hardhat** 或 **Foundry**. + + iii. 為智能合約命名 + + iv. 選擇基本合同類型：**空**、**ERC20**、**ERC721** 或 **ERC1155**。 添加任何所需的**擴展名**。 在本教程中，我們將選擇 ERC721，並將擴展名設置為 "無"。 + +![](/img/build/get-started/thirdweb-cli-info.png) + +3. 創建完成後，請導航至項目根目錄，並在首選代碼編輯器中打開項目。 + +4. 打開合同文件夾，合同應該是這樣的： + +```js +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; +import "@thirdweb-dev/contracts/base/ERC721Base.sol"; +contract nftcollection is ERC721Base { + constructor( + address _defaultAdmin, + string memory _name, + string memory _symbol, + address _royaltyRecipient, + uint128 _royaltyBps + ) + ERC721Base( + _defaultAdmin, + _name, + _symbol, + _royaltyRecipient, + _royaltyBps + ) + {} +} +``` + +上述合約演示了[ERC721Base](https://github.com/thirdweb-dev/contracts/blob/main/contracts/base/ERC721Base.sol) 的基本功能。 它導入並繼承了 **ERC721Base** 合約，還實現了所需的方法，包括構造函數及其從屬參數。 + +您可以根據自己需要的自定義邏輯修改合同，一旦完成，您的合同就可以部署了。 + +### 部署合同 + +1. 導航至項目根文件夾，在終端中運行該命令： + +```bash +npx thirdweb deploy +``` + +執行該命令將觸發以下操作： + +- 檢測框架（硬帽、代工廠） +- 編譯當前目錄下的所有合同。 +- 允許您選擇要部署的合同。 +- 將編譯好的智能合約代碼（以應用程序二進制接口（ABI）的形式）上傳到 IPFS。 + +2. 部署完成後，將打開一個儀錶板界面，填寫其餘參數。 + - **_name**：合同名稱 + - **_symbol**：符號或 "股票代碼" + - **_版稅收款人**：接收二次銷售版稅的錢包地址 + - **_特許權使用費基點**：每次二次銷售將給予特許權使用費收取人的基點 (bps)，如 500 = 5%。 + +3. 選擇 "Kaia Mainnet "作為部署合同的網絡。 + +![](/img/build/get-started/nft-collection-deploy.png) + +4. 智能合約部署完成後，您可以通過其儀錶板管理其他設置和功能。 例如，您可以上傳 NFT、配置權限和訪問控制以及添加新功能。 + +有關 thirdweb 部署命令的更多信息，請參閱 [deploy guide](https://portal.thirdweb.com/deploy/getting-started) 。 + +## 與已部署的合同互動 + +在本節中，我們將分別使用**mint**和**transferfrom**函數鑄造一個 NFT 並將其轉入另一個賬戶。 讓我們按以下步驟來瞭解一下： + +### 鑄幣廠 + +1. 導航至新部署的合同 (**puppyKlan-NC**) 面板。 +2. 點擊合同儀錶板下**NFTs**選項卡中的**mint**功能。 + +![](/img/build/get-started/puppy-mint-btn.png) + +3. 填寫鑄造 NFT 所需的參數：**名稱**、媒體\*\*、描述**和屬性**。 + +![](/img/build/get-started/puppy-mint-details.png) + +4. 核對輸入內容，然後點擊 **Mint NFT** 按鈕。 +5. 確認交易，等待交易完成。 完成後，您會看到儀錶板上添加了 NFT，如下圖所示： + +![](/img/build/get-started/puppy-minted.png) + +### 向新業主轉讓 NFT + +1. 前往合同 (**puppyKlan-NC**) 面板中的資源管理器選項卡。 +2. 在 "寫 "選項卡下選擇 **transferFrom** 功能，如下圖所示。 +3. 填寫必要的函數參數：from（地址）、to（地址）和 id（uint256）。 + +![](/img/build/get-started/puppy-transferfrom.png) + +4. 確認交易，等待交易完成。 + +## 結論 + +祝賀你 如果您讀到了本指南的結尾。 如果您有任何問題，請訪問 [Kaia 論壇](https://devforum.kaia.io/) 或聯繫 [官方第三網絡支持](https://support.thirdweb.com/)。 不過，以下是您在 Kaia 上進一步使用 Thirdweb 時可能需要的有用資源列表。 + +- [Thirdweb文檔](https://portal.thirdweb.com/) +- [如何使用 Thirdweb 構建 dApp](https://blog.thirdweb.com/guides/how-to-build-a-dapp/) +- [使用 NextJS 和 TypeScript 創建自己的 NFT 市場](https://blog.thirdweb.com/guides/nft-marketplace-with-typescript-next/) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md new file mode 100644 index 000000000000..f365a35fd43f --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/ide-and-tools/ide-and-tools.md @@ -0,0 +1,23 @@ +# 集成開發環境和工具 + +本頁包含可用於幫助在 Kaia 上開發智能合約的開發工具列表。 + +#### [Remix Online IDE](https://remix.ethereum.org/) + +Remix Online IDE 是一個功能強大的工具集，用於開發、部署、調試和測試與 EVM 兼容的智能合約。 您可以使用 Kaia Plugin 在 Remix IDE 上編寫、編譯、部署和執行智能合約。 + +#### [凱亞契約精靈](https://wizard.klaytn.foundation/) + +Kaia Contracts Wizard 是一個交互式生成器，用於引導智能合約並瞭解 Kaia Contracts。 它基於 OpenZeppelin 嚮導。 + +#### [Thirdweb](../deploy/thirdweb.md) + +Thirdweb 是一個完整的 Web3 開發框架，可為您提供將應用程序和遊戲連接到去中心化網絡所需的一切。 + +#### [Kaia Wallet](../../tools/wallets/kaia-wallet.md) + +Kaia 錢包是 Kaia 網絡的瀏覽器擴展錢包。 Kaia 錢包使您能夠存儲 KAIA 和基於 Kaia 的代幣並與之互動。 Kaia 錢包還能讓您即時簽署來自基於網絡的 Kaia dApps 的交易。 + +#### [Kaiascope](../../tools/block-explorers/kaiascope.md) + +Kaiascope 是 Kaia 網絡的區塊資源管理器。 您可以在瀏覽器上瀏覽和檢查您的交易。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md new file mode 100644 index 000000000000..484caaa4b429 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/porting-ethereum-contract.md @@ -0,0 +1,41 @@ +# 導入以太坊合約 + +在大多數情況下，您可以在 Kaia 上使用以太坊合約，無需做任何修改。 +不過，要注意以下兩個問題。 + +## 穩固支持 + +- Kairos 網絡目前與**倫敦**以太坊虛擬機 (EVM) 兼容。 +- Mainnet 目前與**倫敦**以太坊虛擬機 (EVM) 兼容。 + +:::note + +v1.7.0 協議升級 - 不兼容的更改，包括**伊斯坦布爾**硬分叉項目和 Kaia 自己的項目。 +如果是 Kairos 網絡，則從區塊編號 "#75,373,312 "開始啟用，如果是主網絡，則從區塊編號 "#86,816,005 "開始啟用。 + +v1.7.3 協議升級 - 包括倫敦\*\*\*硬分叉產生的基本費用在內的不兼容變更。 +如果是 Kairos 網絡，則從區塊編號 "#80,295,291 "開始啟用，如果是主網絡，則從區塊編號 "#86,816,005 "開始啟用。 + +v1.8.0 協議升級 - 包括倫敦\*\*\*硬分叉產生的基本費用在內的不兼容變更。 +如果是 Kairos 網絡，則從區塊編號 "#86,513,895 "開始啟用，如果是主網，則從區塊編號 "#86,816,005 "開始啟用。 + +::: + +不保證向後兼容 Kaia 上的其他 EVM 版本。 +因此，強烈建議根據協議升級狀態使用正確的目標選項編譯 Solidity 代碼。 + +- Kairos: --evm-version london +- Mainnet: --evm-version london +- 其他（私有/服務鏈）：根據協議升級狀態確定 + +請參閱 [如何設置 Solc 的 EVM 版本](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#setting-the-evm-version-to-target)。 + +命令示例如下： + +``` +$ solc --evm-version london contract.sol +``` + +## 解耦密鑰對 + +Kaia [decouples key pairs from addresses](../../learn/accounts.md#decoupling-key-pairs-from-addresses). 如果用戶[更新賬戶](../../learn/transactions/basic.md#txtypeaccountupdate)，特定賬戶的私鑰會被替換為另一個賬戶的私鑰。 大多數情況下，這不會影響您的業務邏輯。 但是，如果您的業務邏輯包括 ecrecover，則應考慮使用 validateSender。 更多詳情，請參閱 [此處](../../learn/computation/precompiled-contracts.md)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md new file mode 100644 index 000000000000..a514429b0aad --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-20.md @@ -0,0 +1,581 @@ +# ERC-20 + +## 導言 + +本教程幫助你創建一個符合[Kaia 代幣標準](../token-standard.md)，尤其是[Fungible Token Standard （ERC-20）](../token-standard.md#fungible-token-standard-kip-7)的ERC-20 兼容代幣示例。 + +[ERC-20令牌標準](https://eips.ethereum.org/EIPS/eip-20) 定義了以下 2 個事件和 9 個方法（包括 3 個可選方法）。 與 ERC-20 兼容的代幣是實現以下接口的代幣合約。 + +```text +function name() public view returns (string) //optional +function symbol() public view returns (string) //optional +function decimals() public view returns (uint8) //optional +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) +function approve(address _spender, uint256 _value) public returns (bool success) +function allowance(address _owner, address _spender) public view returns (uint256 remaining) + +event Transfer(address indexed _from, address indexed _to, uint256 _value) +event Approval(address indexed _owner, address indexed _spender, uint256 _value) +``` + +在上述界面的基礎上，開發人員可以通過添加新功能和邏輯來定製令牌，並將其部署到 Kaia 網絡上。 更多信息，請參閱官方 [ERC-20 文檔](https://eips.ethereum.org/EIPS/eip-20)。 + +在本教程中，您將實現與 ERC-20 兼容的令牌 `MyERC20.sol`。 該代幣將發行預定數量的代幣，並在部署時將所有代幣發送給合約所有者。 + +MyERC20.sol "基於 OpenZeppelin 的 ERC20 實現。 本教程的大部分代碼來自 [OpenZeppelin 2.3 ](https://github.com/OpenZeppelin/openzeppelin-solidity/releases/tag/v2.3.0)，以下 Solidity 文件用於實現 `MyERC20.sol`。 + +- [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/IERC20.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/IERC20.sol) +- [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20.sol) +- [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Detailed.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Detailed.sol) +- [https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/math/SafeMath.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/math/SafeMath.sol) + +## 1. 編寫 ERC-20 智能合約 + +### 1.1 MyERC20 的總體結構 + +MyERC20.sol "的完整源代碼如下。 在此實現中，"構造器 "調用 "鑄幣"，在部署合約時鑄入預定數量的代幣。 + +```text +pragma solidity ^0.5.0; + +/** + * @dev Interface of the ERC20 standard as defined in the EIP. Does not include + * the optional functions; to access them see `ERC20Detailed`. + */ +interface IERC20 { + function totalSupply() external view returns (uint256); + + function balanceOf(address account) external view returns (uint256); + + function transfer(address recipient, uint256 amount) external returns (bool); + + function allowance(address owner, address spender) external view returns (uint256); + + function approve(address spender, uint256 amount) external returns (bool); + + function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); + + event Transfer(address indexed from, address indexed to, uint256 value); + + event Approval(address indexed owner, address indexed spender, uint256 value); +} + +library SafeMath { + /** + * @dev Returns the addition of two unsigned integers, reverting on + * overflow. + * + * Counterpart to Solidity's `+` operator. + * + * Requirements: + * - Addition cannot overflow. + */ + function add(uint256 a, uint256 b) internal pure returns (uint256) { + uint256 c = a + b; + require(c >= a, "SafeMath: addition overflow"); + + return c; + } + + /** + * @dev Returns the subtraction of two unsigned integers, reverting on + * overflow (when the result is negative). + * + * Counterpart to Solidity's `-` operator. + * + * Requirements: + * - Subtraction cannot overflow. + */ + function sub(uint256 a, uint256 b) internal pure returns (uint256) { + require(b <= a, "SafeMath: subtraction overflow"); + uint256 c = a - b; + + return c; + } + + /** + * @dev Returns the multiplication of two unsigned integers, reverting on + * overflow. + * + * Counterpart to Solidity's `*` operator. + * + * Requirements: + * - Multiplication cannot overflow. + */ + function mul(uint256 a, uint256 b) internal pure returns (uint256) { + // Gas optimization: this is cheaper than requiring 'a' not being zero, but the + // benefit is lost if 'b' is also tested. + // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522 + if (a == 0) { + return 0; + } + + uint256 c = a * b; + require(c / a == b, "SafeMath: multiplication overflow"); + + return c; + } + + /** + * @dev Returns the integer division of two unsigned integers. Reverts on + * division by zero. The result is rounded towards zero. + * + * Counterpart to Solidity's `/` operator. Note: this function uses a + * `revert` opcode (which leaves remaining gas untouched) while Solidity + * uses an invalid opcode to revert (consuming all remaining gas). + * + * Requirements: + * - The divisor cannot be zero. + */ + function div(uint256 a, uint256 b) internal pure returns (uint256) { + // Solidity only automatically asserts when dividing by 0 + require(b > 0, "SafeMath: division by zero"); + uint256 c = a / b; + // assert(a == b * c + a % b); // There is no case in which this doesn't hold + + return c; + } + + /** + * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), + * Reverts when dividing by zero. + * + * Counterpart to Solidity's `%` operator. This function uses a `revert` + * opcode (which leaves remaining gas untouched) while Solidity uses an + * invalid opcode to revert (consuming all remaining gas). + * + * Requirements: + * - The divisor cannot be zero. + */ + function mod(uint256 a, uint256 b) internal pure returns (uint256) { + require(b != 0, "SafeMath: modulo by zero"); + return a % b; + } +} + +/** + * @dev Implementation of the `IERC20` interface. + * + * This implementation is agnostic to the way tokens are created. This means + * that a supply mechanism has to be added in a derived contract using `_mint`. + * For a generic mechanism see `ERC20Mintable`. + * + * *For a detailed writeup see our guide [How to implement supply + * mechanisms](https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226).* + * + * We have followed general OpenZeppelin guidelines: functions revert instead + * of returning `false` on failure. This behavior is nonetheless conventional + * and does not conflict with the expectations of ERC20 applications. + * + * Additionally, an `Approval` event is emitted on calls to `transferFrom`. + * This allows applications to reconstruct the allowance for all accounts just + * by listening to said events. Other implementations of the EIP may not emit + * these events, as it isn't required by the specification. + * + * Finally, the non-standard `decreaseAllowance` and `increaseAllowance` + * functions have been added to mitigate the well-known issues around setting + * allowances. See `IERC20.approve`. + */ +contract MyERC20 is IERC20 { + using SafeMath for uint256; + + mapping (address => uint256) private _balances; + + mapping (address => mapping (address => uint256)) private _allowances; + + // NOTE Start of https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Detailed.sol + string private _name; + string private _symbol; + uint8 private _decimals; + + constructor (string memory name, string memory symbol, uint8 decimals) public { + _name = name; + _symbol = symbol; + _decimals = decimals; + + _mint(msg.sender, 100000 * 10 ** uint256(decimals)); // CAUTION! + } + + /** + * @dev Returns the name of the token. + */ + function name() public view returns (string memory) { + return _name; + } + + /** + * @dev Returns the symbol of the token, usually a shorter version of the + * name. + */ + function symbol() public view returns (string memory) { + return _symbol; + } + + /** + * @dev Returns the number of decimals used to get its user representation. + * For example, if `decimals` equals `2`, a balance of `505` tokens should + * be displayed to a user as `5,05` (`505 / 10 ** 2`). + * + * Tokens usually opt for a value of 18, imitating the relationship between + * Ether and Wei. + * + * > Note that this information is only used for _display_ purposes: it in + * no way affects any of the arithmetic of the contract, including + * `IERC20.balanceOf` and `IERC20.transfer`. + */ + function decimals() public view returns (uint8) { + return _decimals; + } + // NOTE End of https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Detailed.sol + + uint256 private _totalSupply; + + /** + * @dev See `IERC20.totalSupply`. + */ + function totalSupply() public view returns (uint256) { + return _totalSupply; + } + + /** + * @dev See `IERC20.balanceOf`. + */ + function balanceOf(address account) public view returns (uint256) { + return _balances[account]; + } + + /** + * @dev See `IERC20.transfer`. + * + * Requirements: + * + * - `recipient` cannot be the zero address. + * - the caller must have a balance of at least `amount`. + */ + function transfer(address recipient, uint256 amount) public returns (bool) { + _transfer(msg.sender, recipient, amount); + return true; + } + + /** + * @dev See `IERC20.allowance`. + */ + function allowance(address owner, address spender) public view returns (uint256) { + return _allowances[owner][spender]; + } + + /** + * @dev See `IERC20.approve`. + * + * Requirements: + * + * - `spender` cannot be the zero address. + */ + function approve(address spender, uint256 value) public returns (bool) { + _approve(msg.sender, spender, value); + return true; + } + + /** + * @dev See `IERC20.transferFrom`. + * + * Emits an `Approval` event indicating the updated allowance. This is not + * required by the EIP. See the note at the beginning of `ERC20`; + * + * Requirements: + * - `sender` and `recipient` cannot be the zero address. + * - `sender` must have a balance of at least `value`. + * - the caller must have allowance for `sender`'s tokens of at least + * `amount`. + */ + function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) { + _transfer(sender, recipient, amount); + _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount)); + return true; + } + + /** + * @dev Atomically increases the allowance granted to `spender` by the caller. + * + * This is an alternative to `approve` that can be used as a mitigation for + * problems described in `IERC20.approve`. + * + * Emits an `Approval` event indicating the updated allowance. + * + * Requirements: + * + * - `spender` cannot be the zero address. + */ + function increaseAllowance(address spender, uint256 addedValue) public returns (bool) { + _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue)); + return true; + } + + /** + * @dev Atomically decreases the allowance granted to `spender` by the caller. + * + * This is an alternative to `approve` that can be used as a mitigation for + * problems described in `IERC20.approve`. + * + * Emits an `Approval` event indicating the updated allowance. + * + * Requirements: + * + * - `spender` cannot be the zero address. + * - `spender` must have allowance for the caller of at least + * `subtractedValue`. + */ + function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) { + _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue)); + return true; + } + + /** + * @dev Moves tokens `amount` from `sender` to `recipient`. + * + * This is internal function is equivalent to `transfer`, and can be used to + * e.g. implement automatic token fees, slashing mechanisms, etc. + * + * Emits a `Transfer` event. + * + * Requirements: + * + * - `sender` cannot be the zero address. + * - `recipient` cannot be the zero address. + * - `sender` must have a balance of at least `amount`. + */ + function _transfer(address sender, address recipient, uint256 amount) internal { + require(sender != address(0), "ERC20: transfer from the zero address"); + require(recipient != address(0), "ERC20: transfer to the zero address"); + + _balances[sender] = _balances[sender].sub(amount); + _balances[recipient] = _balances[recipient].add(amount); + emit Transfer(sender, recipient, amount); + } + + /** @dev Creates `amount` tokens and assigns them to `account`, increasing + * the total supply. + * + * Emits a `Transfer` event with `from` set to the zero address. + * + * Requirements + * + * - `to` cannot be the zero address. + */ + function _mint(address account, uint256 amount) internal { + require(account != address(0), "ERC20: mint to the zero address"); + + _totalSupply = _totalSupply.add(amount); + _balances[account] = _balances[account].add(amount); + emit Transfer(address(0), account, amount); + } + + /** + * @dev Destroys `amount` tokens from `account`, reducing the + * total supply. + * + * Emits a `Transfer` event with `to` set to the zero address. + * + * Requirements + * + * - `account` cannot be the zero address. + * - `account` must have at least `amount` tokens. + */ + function _burn(address account, uint256 value) internal { + require(account != address(0), "ERC20: burn from the zero address"); + + _balances[account] = _balances[account].sub(value); + _totalSupply = _totalSupply.sub(value); + emit Transfer(account, address(0), value); + } + + /** + * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens. + * + * This is internal function is equivalent to `approve`, and can be used to + * e.g. set automatic allowances for certain subsystems, etc. + * + * Emits an `Approval` event. + * + * Requirements: + * + * - `owner` cannot be the zero address. + * - `spender` cannot be the zero address. + */ + function _approve(address owner, address spender, uint256 value) internal { + require(owner != address(0), "ERC20: approve from the zero address"); + require(spender != address(0), "ERC20: approve to the zero address"); + + _allowances[owner][spender] = value; + emit Approval(owner, spender, value); + } + + /** + * @dev Destoys `amount` tokens from `account`.`amount` is then deducted + * from the caller's allowance. + * + * See `_burn` and `_approve`. + */ + function _burnFrom(address account, uint256 amount) internal { + _burn(account, amount); + _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount)); + } +} +``` + +MyERC20.sol "由一個接口 "IERC20"、一個庫 "SafeMath "和一個實現 "IERC20 "接口的合約 "MyERC20 "組成。 + +- IERC20 "接口定義了[ERC-20 規範](https://eips.ethereum.org/EIPS/eip-20) 中描述的強制接口。 +- SafeMath "庫定義了 Solidity 算術運算的包裝器，並增加了溢出檢查功能，可安全計算 Solidity 的 "uint256 "類型。 +- MyERC20 "實現了 "IERC20 "接口，還定義了三個可選方法，詳見[ERC-20 規範](https://eips.ethereum.org/EIPS/eip-20)。 + - 除 ERC20 外，還定義了 "構造器"，該構造器用於定義新的 ERC20 令牌名稱和符號，並鑄造預定數量的令牌。 `constructor` 在首次部署時被調用一次。 + +### 1.2 看看重要的方法 + +讓我們來詳細瞭解一些重要的方法。 + +#### \(1\) `function balanceOf(address account) external view returns (uint256);` + +balanceOf "是 ERC-20 的強制方法。 `balanceOf` 返回給定地址的餘額。 + +```text + function balanceOf(address account) public view returns (uint256) { + return _balances[account]; + } +``` + +`balanceOf` 只返回存儲在 `_balances`中的 key`account` 的值，它是 `mapping (address => uint256)`類型，如下所示。 + +```text + mapping (address => uint256) private _balances; +``` + +如果 `_balances`中沒有可用的 key `account` ，則只會返回 `0`。 + +#### \(2\) `function transfer(address recipient, uint256 amount) external returns (bool);` + +轉讓 "是 ERC-20 的強制性方法。 transfer "會將 "數量 "代幣轉移給 "接收方"，並且必須觸發 "Transfer "事件。 如果消息調用者的賬戶餘額沒有足夠的代幣可供使用，函數應拋出。 + +transfer "只是調用內部方法"_transfer"，它實現的實際傳輸和事件如下。 + +```text + function transfer(address recipient, uint256 amount) public returns (bool) { + _transfer(msg.sender, recipient, amount); + return true; + } +``` + +`_transfer` 實現 ERC-20 的 `transfer` 方法的實際行為。 + +此外，它還能防止使用下面的 `require` 從零地址或向零地址發送令牌。 + +```text + function _transfer(address sender, address recipient, uint256 amount) internal { + require(sender != address(0), "ERC20: transfer from the zero address"); + require(recipient != address(0), "ERC20: transfer to the zero address"); + + _balances[sender] = _balances[sender].sub(amount); + _balances[recipient] = _balances[recipient].add(amount); + emit Transfer(sender, recipient, amount); + } +``` + +#### \(3\) `function approve(address spender, uint256 amount) external returns (bool);` + +批准 "是 ERC-20 的強制性方法。 批准 "允許 "支出人 "多次從您的賬戶中提款，但以 "金額 "為限。 如果多次調用此函數，則會將津貼重置為 `amount`。 + +approve "只是調用內部方法"_approve"，它實現了 "approve "的實際行為。 msg.sender "作為賬戶 "owner "傳遞。 + +```text + function approve(address spender, uint256 value) public returns (bool) { + _approve(msg.sender, spender, value); + return true; + } + + function _approve(address owner, address spender, uint256 value) internal { + require(owner != address(0), "ERC20: approve from the zero address"); + require(spender != address(0), "ERC20: approve to the zero address"); + + _allowances[owner][spender] = value; + emit Approval(owner, spender, value); + } +``` + +批准 "更新 "允許值"，"允許值 "是一個二維字典，保存了特定 "地址 "的 "支出人 "的允許 "值"。 + +```text + mapping (address => mapping (address => uint256)) private _allowances; +``` + +#### \(4\) `function _mint(address account, uint256 amount) internal` + +`_mint` 不是 ERC-20 的一部分。 但是，我們需要一種方法來創建新的 ERC-20 令牌，因此在此實現中引入了 `_mint` 來創建新令牌，如下所示。 + +```text + function _mint(address account, uint256 amount) internal { + require(account != address(0), "ERC20: mint to the zero address"); + + _totalSupply = _totalSupply.add(amount); + _balances[account] = _balances[account].add(amount); + emit Transfer(address(0), account, amount); + } +``` + +`_mint` 是一個內部方法，可在本合同內部調用。 + +在`MyERC20.sol`中，當部署智能合約以鑄造預定數量的代幣時，`_mint`只從`constructor`調用一次。 + +如果想在部署智能合約後發行額外的代幣，就必須引入一個新的公共方法，如 `mint`。 實施該方法時應小心謹慎，因為只有授權用戶才能鑄造令牌。 + +更多詳情，請參閱 OpenZeppelin 示例 [ERC20Mintable.sol](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC20/ERC20Mintable.sol)。 + +## 2. 部署智能合約 + +在本節中，您將使用 Remix Online IDE 部署 MyERC20 智能合約。 MYERC20.sol 的完整源代碼見 [編寫 ERC-20 智能合約](https://docs.kaia.io/build/smart-contracts/samples/erc-20/#1-writing-erc-20-smart-contract)。 + +### 2.1 先決條件 + +- [Kaia Wallet](../../tools/wallets/kaia-wallet.md)：用於部署合約、簽署交易和與合約交互。 +- 從 [水龍頭](https://faucet.kaia.io)測試 KAIA：為賬戶注入足夠的 KAIA。 + +你可以使用 Remix Online IDE 或 Truffle 來部署 `MyERC20` 智能合約。 + +### 2.2 使用 Remix 在線集成開發環境部署智能合約 + +Remix IDE + +- 導航至 [Kaia Remix 插件](https://ide.kaia.io/) +- 在合同文件夾中創建一個 `MyERC20.sol` 文件 +- 在 Remix 中，點擊**編譯**合同。 +- 安裝插件後，點擊左側的 Kaia（前 Klaytn）選項卡 +- 選擇 **環境** > **注入式提供商** - **Kaia Wallet**。 +- 在合同字段中，選擇您的合同。 例如，MyERC20。 +- 在部署 **KAIROSTOKEN**、**KAIROS** 和 **8** 時分配以下參數 +- 點擊 **部署**。 + +![ERC20-1-deploy](/img/build/smart-contracts/remix-layout-erc20-example.png) + +部署完成後，可以使用用於部署合同的賬戶調用 `balanceOf` 。 您會發現您的賬戶中有 `10000000000000` 代幣，如下所示。 由於您在部署上述合約時將 `decimal` 設置為 `8`，因此它在構造器中鑄造了固定數量的 `100000` 代幣，其中一個代幣的十進制值為 `10^8`。 totalSupply "方法將返回已鑄造代幣的總供應量，也應為 "10000000000000"。 + +![ERC20-2-owner-token](/img/build/smart-contracts/bal-ts-erc20-example.png) + +MyERC20 "現已上線！ + +## 3. 與 Kaia 錢包中的 ERC-20 令牌互動 + +您可以使用 Kaia 錢包查看餘額，並轉移您剛剛部署的與 ERC-20 兼容的 KAIROSTOKEN。 要在 Kaia 錢包中查看令牌餘額，請按以下步驟操作： + +Kaia 錢包 + +- 打開 Kaia 錢包 +- 點擊令牌列表圖標，然後點擊添加令牌按鈕 + +![](/img/build/smart-contracts/kaia-add-token-kw.png) + +- 在 "自定義令牌 "選項卡下的 "令牌合約地址 "字段中粘貼 myERC20.sol 合約的地址。 +- 然後按照提示添加令牌。 您的令牌列表模式應該是這樣的： + +![](/img/build/smart-contracts/kaia-add-token-kw-ii.png) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md new file mode 100644 index 000000000000..c77d0ed875e0 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/erc-721.md @@ -0,0 +1,843 @@ +# ERC-721 + +## 導言 + +本教程可幫助您創建一個符合[Kaia 令牌標準](../token-standard.md)，尤其是[不可篡改令牌標準（ERC-721）](../token-standard.md#non-fungible-token-standard-kip-17)的ERC-721兼容令牌示例。 + +[ERC-721不可封代幣標準](https://eips.ethereum.org/EIPS/eip-721) 定義了以下三個事件和 10 種方法。 ERC-721 的 `supportsInterface` 源自 [ERC-165 標準接口檢測](https://eips.ethereum.org/EIPS/eip-165)，ERC-165 是 ERC-721 的一部分。 +ERC-721兼容代幣是實施ERC-721和ERC-165接口的代幣合約，具體如下。 + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); +event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); +event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); + +function balanceOf(address _owner) external view returns (uint256); +function ownerOf(uint256 _tokenId) external view returns (address); +function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; +function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; +function transferFrom(address _from, address _to, uint256 _tokenId) external payable; +function approve(address _approved, uint256 _tokenId) external payable; +function setApprovalForAll(address _operator, bool _approved) external; +function getApproved(uint256 _tokenId) external view returns (address); +function isApprovedForAll(address _owner, address _operator) external view returns (bool); +function supportsInterface(bytes4 interfaceID) external view returns (bool); +``` + +在上述界面的基礎上，開發人員可以通過添加新功能和邏輯來定製令牌，並將其部署到 Kaia 網絡上。 +更多信息，請參閱官方[ERC-721 規範](https://eips.ethereum.org/EIPS/eip-721)。 + +在本教程中，您將實現 "MyERC721Card.sol"，它將實現一種卡片類型的不可篡改令牌，即 "MyERC721Card"，它是一種ERC-721令牌。 +每張 "MyERC721Card "都有名稱和級別，例如 "King"（國王）的級別為 1，"Queen"（王后）的級別為 1。 + +MyERC721Card.sol "基於 OpenZeppelin 的 ERC721 實現。 本教程的大部分代碼來自 OpenZeppelin 2.3 +。 + +## 1. 編寫 ERC-721 智能合約 + +### 1.1 MyERC721Card 的總體結構 + +MyERC721Card.sol\` 的完整源代碼如下。 + +```text +pragma solidity ^0.5.0; + +// https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/utils/Address.sol +/** + * @dev Collection of functions related to the address type, + */ +library Address { + /** + * @dev Returns true if `account` is a contract. + * + * This test is non-exhaustive, and there may be false-negatives: during the + * execution of a contract's constructor, its address will be reported as + * not containing a contract. + * + * > It is unsafe to assume that an address for which this function returns + * false is an externally-owned account (EOA) and not a contract. + */ + function isContract(address account) internal view returns (bool) { + // This method relies in extcodesize, which returns 0 for contracts in + // construction, since the code is only stored at the end of the + // constructor execution. + + uint256 size; + // solhint-disable-next-line no-inline-assembly + assembly { size := extcodesize(account) } + return size > 0; + } +} + +// https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/math/SafeMath.sol +/** + * @dev Wrappers over Solidity's arithmetic operations with added overflow + * checks. + * + * Arithmetic operations in Solidity wrap on overflow. This can easily result + * in bugs, because programmers usually assume that an overflow raises an + * error, which is the standard behavior in high level programming languages. + * `SafeMath` restores this intuition by reverting the transaction when an + * operation overflows. + * + * Using this library instead of the unchecked operations eliminates an entire + * class of bugs, so it's recommended to use it always. + */ +library SafeMath { + /** + * @dev Returns the addition of two unsigned integers, reverting on + * overflow. + * + * Counterpart to Solidity's `+` operator. + * + * Requirements: + * - Addition cannot overflow. + */ + function add(uint256 a, uint256 b) internal pure returns (uint256) { + uint256 c = a + b; + require(c >= a, "SafeMath: addition overflow"); + + return c; + } + + /** + * @dev Returns the subtraction of two unsigned integers, reverting on + * overflow (when the result is negative). + * + * Counterpart to Solidity's `-` operator. + * + * Requirements: + * - Subtraction cannot overflow. + */ + function sub(uint256 a, uint256 b) internal pure returns (uint256) { + require(b <= a, "SafeMath: subtraction overflow"); + uint256 c = a - b; + + return c; + } + + /** + * @dev Returns the multiplication of two unsigned integers, reverting on + * overflow. + * + * Counterpart to Solidity's `*` operator. + * + * Requirements: + * - Multiplication cannot overflow. + */ + function mul(uint256 a, uint256 b) internal pure returns (uint256) { + // Gas optimization: this is cheaper than requiring 'a' not being zero, but the + // benefit is lost if 'b' is also tested. + // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522 + if (a == 0) { + return 0; + } + + uint256 c = a * b; + require(c / a == b, "SafeMath: multiplication overflow"); + + return c; + } + + /** + * @dev Returns the integer division of two unsigned integers. Reverts on + * division by zero. The result is rounded towards zero. + * + * Counterpart to Solidity's `/` operator. Note: this function uses a + * `revert` opcode (which leaves remaining gas untouched) while Solidity + * uses an invalid opcode to revert (consuming all remaining gas). + * + * Requirements: + * - The divisor cannot be zero. + */ + function div(uint256 a, uint256 b) internal pure returns (uint256) { + // Solidity only automatically asserts when dividing by 0 + require(b > 0, "SafeMath: division by zero"); + uint256 c = a / b; + // assert(a == b * c + a % b); // There is no case in which this doesn't hold + + return c; + } + + /** + * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), + * Reverts when dividing by zero. + * + * Counterpart to Solidity's `%` operator. This function uses a `revert` + * opcode (which leaves remaining gas untouched) while Solidity uses an + * invalid opcode to revert (consuming all remaining gas). + * + * Requirements: + * - The divisor cannot be zero. + */ + function mod(uint256 a, uint256 b) internal pure returns (uint256) { + require(b != 0, "SafeMath: modulo by zero"); + return a % b; + } +} + +// https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/drafts/Counters.sol +/** + * @title Counters + * @author Matt Condon (@shrugs) + * @dev Provides counters that can only be incremented or decremented by one. This can be used e.g. to track the number + * of elements in a mapping, issuing ERC721 ids, or counting request ids. + * + * Include with `using Counters for Counters.Counter;` + * Since it is not possible to overflow a 256 bit integer with increments of one, `increment` can skip the SafeMath + * overflow check, thereby saving gas. This does assume however correct usage, in that the underlying `_value` is never + * directly accessed. + */ +library Counters { + using SafeMath for uint256; + + struct Counter { + // This variable should never be directly accessed by users of the library: interactions must be restricted to + // the library's function. As of Solidity v0.5.2, this cannot be enforced, though there is a proposal to add + // this feature: see https://github.com/ethereum/solidity/issues/4637 + uint256 _value; // default: 0 + } + + function current(Counter storage counter) internal view returns (uint256) { + return counter._value; + } + + function increment(Counter storage counter) internal { + counter._value += 1; + } + + function decrement(Counter storage counter) internal { + counter._value = counter._value.sub(1); + } +} + +/** + * @dev Interface of the ERC165 standard, as defined in the + * [EIP](https://eips.ethereum.org/EIPS/eip-165). + * + * Implementers can declare support of contract interfaces, which can then be + * queried by others (`ERC165Checker`). + * + * For an implementation, see `ERC165`. + */ +interface IERC165 { + /** + * @dev Returns true if this contract implements the interface defined by + * `interfaceId`. See the corresponding + * [EIP section](https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified) + * to learn more about how these ids are created. + * + * This function call must use less than 30 000 gas. + */ + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} + +/** + * @dev Implementation of the `IERC165` interface. + * + * Contracts may inherit from this and call `_registerInterface` to declare + * their support of an interface. + */ +contract ERC165 is IERC165 { + /* + * bytes4(keccak256('supportsInterface(bytes4)')) == 0x01ffc9a7 + */ + bytes4 private constant _INTERFACE_ID_ERC165 = 0x01ffc9a7; + + /** + * @dev Mapping of interface ids to whether or not it's supported. + */ + mapping(bytes4 => bool) private _supportedInterfaces; + + constructor () internal { + // Derived contracts need only register support for their own interfaces, + // we register support for ERC165 itself here + _registerInterface(_INTERFACE_ID_ERC165); + } + + /** + * @dev See `IERC165.supportsInterface`. + * + * Time complexity O(1), guaranteed to always use less than 30 000 gas. + */ + function supportsInterface(bytes4 interfaceId) external view returns (bool) { + return _supportedInterfaces[interfaceId]; + } + + /** + * @dev Registers the contract as an implementer of the interface defined by + * `interfaceId`. Support of the actual ERC165 interface is automatic and + * registering its interface id is not required. + * + * See `IERC165.supportsInterface`. + * + * Requirements: + * + * - `interfaceId` cannot be the ERC165 invalid interface (`0xffffffff`). + */ + function _registerInterface(bytes4 interfaceId) internal { + require(interfaceId != 0xffffffff, "ERC165: invalid interface id"); + _supportedInterfaces[interfaceId] = true; + } +} + +/** + * @dev Required interface of an ERC721 compliant contract. + */ +contract IERC721 is IERC165 { + event Transfer(address indexed from, address indexed to, uint256 indexed tokenId); + event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId); + event ApprovalForAll(address indexed owner, address indexed operator, bool approved); + + /** + * @dev Returns the number of NFTs in `owner`'s account. + */ + function balanceOf(address owner) public view returns (uint256 balance); + + /** + * @dev Returns the owner of the NFT specified by `tokenId`. + */ + function ownerOf(uint256 tokenId) public view returns (address owner); + + /** + * @dev Transfers a specific NFT (`tokenId`) from one account (`from`) to + * another (`to`). + * + * + * + * Requirements: + * - `from`, `to` cannot be zero. + * - `tokenId` must be owned by `from`. + * - If the caller is not `from`, it must be have been allowed to move this + * NFT by either `approve` or `setApproveForAll`. + */ + function safeTransferFrom(address from, address to, uint256 tokenId) public; + /** + * @dev Transfers a specific NFT (`tokenId`) from one account (`from`) to + * another (`to`). + * + * Requirements: + * - If the caller is not `from`, it must be approved to move this NFT by + * either `approve` or `setApproveForAll`. + */ + function transferFrom(address from, address to, uint256 tokenId) public; + function approve(address to, uint256 tokenId) public; + function getApproved(uint256 tokenId) public view returns (address operator); + + function setApprovalForAll(address operator, bool _approved) public; + function isApprovedForAll(address owner, address operator) public view returns (bool); + + + function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public; +} + +// https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC721/IERC721Receiver.sol +/** + * @title ERC721 token receiver interface + * @dev Interface for any contract that wants to support safeTransfers + * from ERC721 asset contracts. + */ +contract IERC721Receiver { + /** + * @notice Handle the receipt of an NFT + * @dev The ERC721 smart contract calls this function on the recipient + * after a `safeTransfer`. This function MUST return the function selector, + * otherwise the caller will revert the transaction. The selector to be + * returned can be obtained as `this.onERC721Received.selector`. This + * function MAY throw to revert and reject the transfer. + * Note: the ERC721 contract address is always the message sender. + * @param operator The address which called `safeTransferFrom` function + * @param from The address which previously owned the token + * @param tokenId The NFT identifier which is being transferred + * @param data Additional data with no specified format + * @return bytes4 `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))` + */ + function onERC721Received(address operator, address from, uint256 tokenId, bytes memory data) + public returns (bytes4); +} + +// https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.3.0/contracts/token/ERC721/ERC721.sol +contract ERC721 is ERC165, IERC721 { + using SafeMath for uint256; + using Address for address; + using Counters for Counters.Counter; + + // Equals to `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))` + // which can be also obtained as `IERC721Receiver(0).onERC721Received.selector` + bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; + + // Mapping from token ID to owner + mapping (uint256 => address) private _tokenOwner; + + // Mapping from token ID to approved address + mapping (uint256 => address) private _tokenApprovals; + + // Mapping from owner to number of owned token + mapping (address => Counters.Counter) private _ownedTokensCount; + + // Mapping from owner to operator approvals + mapping (address => mapping (address => bool)) private _operatorApprovals; + + /* + * bytes4(keccak256('balanceOf(address)')) == 0x70a08231 + * bytes4(keccak256('ownerOf(uint256)')) == 0x6352211e + * bytes4(keccak256('approve(address,uint256)')) == 0x095ea7b3 + * bytes4(keccak256('getApproved(uint256)')) == 0x081812fc + * bytes4(keccak256('setApprovalForAll(address,bool)')) == 0xa22cb465 + * bytes4(keccak256('isApprovedForAll(address,address)')) == 0xe985e9c + * bytes4(keccak256('transferFrom(address,address,uint256)')) == 0x23b872dd + * bytes4(keccak256('safeTransferFrom(address,address,uint256)')) == 0x42842e0e + * bytes4(keccak256('safeTransferFrom(address,address,uint256,bytes)')) == 0xb88d4fde + * + * => 0x70a08231 ^ 0x6352211e ^ 0x095ea7b3 ^ 0x081812fc ^ + * 0xa22cb465 ^ 0xe985e9c ^ 0x23b872dd ^ 0x42842e0e ^ 0xb88d4fde == 0x80ac58cd + */ + bytes4 private constant _INTERFACE_ID_ERC721 = 0x80ac58cd; + + constructor () public { + // register the supported interfaces to conform to ERC721 via ERC165 + _registerInterface(_INTERFACE_ID_ERC721); + } + + /** + * @dev Gets the balance of the specified address. + * @param owner address to query the balance of + * @return uint256 representing the amount owned by the passed address + */ + function balanceOf(address owner) public view returns (uint256) { + require(owner != address(0), "ERC721: balance query for the zero address"); + + return _ownedTokensCount[owner].current(); + } + + /** + * @dev Gets the owner of the specified token ID. + * @param tokenId uint256 ID of the token to query the owner of + * @return address currently marked as the owner of the given token ID + */ + function ownerOf(uint256 tokenId) public view returns (address) { + address owner = _tokenOwner[tokenId]; + require(owner != address(0), "ERC721: owner query for nonexistent token"); + + return owner; + } + + /** + * @dev Approves another address to transfer the given token ID + * The zero address indicates there is no approved address. + * There can only be one approved address per token at a given time. + * Can only be called by the token owner or an approved operator. + * @param to address to be approved for the given token ID + * @param tokenId uint256 ID of the token to be approved + */ + function approve(address to, uint256 tokenId) public { + address owner = ownerOf(tokenId); + require(to != owner, "ERC721: approval to current owner"); + + require(msg.sender == owner || isApprovedForAll(owner, msg.sender), + "ERC721: approve caller is not owner nor approved for all" + ); + + _tokenApprovals[tokenId] = to; + emit Approval(owner, to, tokenId); + } + + /** + * @dev Gets the approved address for a token ID, or zero if no address set + * Reverts if the token ID does not exist. + * @param tokenId uint256 ID of the token to query the approval of + * @return address currently approved for the given token ID + */ + function getApproved(uint256 tokenId) public view returns (address) { + require(_exists(tokenId), "ERC721: approved query for nonexistent token"); + + return _tokenApprovals[tokenId]; + } + + /** + * @dev Sets or unsets the approval of a given operator + * An operator is allowed to transfer all tokens of the sender on their behalf. + * @param to operator address to set the approval + * @param approved representing the status of the approval to be set + */ + function setApprovalForAll(address to, bool approved) public { + require(to != msg.sender, "ERC721: approve to caller"); + + _operatorApprovals[msg.sender][to] = approved; + emit ApprovalForAll(msg.sender, to, approved); + } + + /** + * @dev Tells whether an operator is approved by a given owner. + * @param owner owner address which you want to query the approval of + * @param operator operator address which you want to query the approval of + * @return bool whether the given operator is approved by the given owner + */ + function isApprovedForAll(address owner, address operator) public view returns (bool) { + return _operatorApprovals[owner][operator]; + } + + /** + * @dev Transfers the ownership of a given token ID to another address. + * Usage of this method is discouraged, use `safeTransferFrom` whenever possible. + * Requires the msg.sender to be the owner, approved, or operator. + * @param from current owner of the token + * @param to address to receive the ownership of the given token ID + * @param tokenId uint256 ID of the token to be transferred + */ + function transferFrom(address from, address to, uint256 tokenId) public { + //solhint-disable-next-line max-line-length + require(_isApprovedOrOwner(msg.sender, tokenId), "ERC721: transfer caller is not owner nor approved"); + + _transferFrom(from, to, tokenId); + } + + /** + * @dev Safely transfers the ownership of a given token ID to another address + * If the target address is a contract, it must implement `onERC721Received`, + * which is called upon a safe transfer, and return the magic value + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; otherwise, + * the transfer is reverted. + * Requires the msg.sender to be the owner, approved, or operator + * @param from current owner of the token + * @param to address to receive the ownership of the given token ID + * @param tokenId uint256 ID of the token to be transferred + */ + function safeTransferFrom(address from, address to, uint256 tokenId) public { + safeTransferFrom(from, to, tokenId, ""); + } + + /** + * @dev Safely transfers the ownership of a given token ID to another address + * If the target address is a contract, it must implement `onERC721Received`, + * which is called upon a safe transfer, and return the magic value + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; otherwise, + * the transfer is reverted. + * Requires the msg.sender to be the owner, approved, or operator + * @param from current owner of the token + * @param to address to receive the ownership of the given token ID + * @param tokenId uint256 ID of the token to be transferred + * @param _data bytes data to send along with a safe transfer check + */ + function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public { + transferFrom(from, to, tokenId); + require(_checkOnERC721Received(from, to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer"); + } + + /** + * @dev Returns whether the specified token exists. + * @param tokenId uint256 ID of the token to query the existence of + * @return bool whether the token exists + */ + function _exists(uint256 tokenId) internal view returns (bool) { + address owner = _tokenOwner[tokenId]; + return owner != address(0); + } + + /** + * @dev Returns whether the given spender can transfer a given token ID. + * @param spender address of the spender to query + * @param tokenId uint256 ID of the token to be transferred + * @return bool whether the msg.sender is approved for the given token ID, + * is an operator of the owner, or is the owner of the token + */ + function _isApprovedOrOwner(address spender, uint256 tokenId) internal view returns (bool) { + require(_exists(tokenId), "ERC721: operator query for nonexistent token"); + address owner = ownerOf(tokenId); + return (spender == owner || getApproved(tokenId) == spender || isApprovedForAll(owner, spender)); + } + + /** + * @dev Internal function to mint a new token. + * Reverts if the given token ID already exists. + * @param to The address that will own the minted token + * @param tokenId uint256 ID of the token to be minted + */ + function _mint(address to, uint256 tokenId) internal { + require(to != address(0), "ERC721: mint to the zero address"); + require(!_exists(tokenId), "ERC721: token already minted"); + + _tokenOwner[tokenId] = to; + _ownedTokensCount[to].increment(); + + emit Transfer(address(0), to, tokenId); + } + + /** + * @dev Internal function to burn a specific token. + * Reverts if the token does not exist. + * Deprecated, use _burn(uint256) instead. + * @param owner owner of the token to burn + * @param tokenId uint256 ID of the token being burned + */ + function _burn(address owner, uint256 tokenId) internal { + require(ownerOf(tokenId) == owner, "ERC721: burn of token that is not own"); + + _clearApproval(tokenId); + + _ownedTokensCount[owner].decrement(); + _tokenOwner[tokenId] = address(0); + + emit Transfer(owner, address(0), tokenId); + } + + /** + * @dev Internal function to burn a specific token. + * Reverts if the token does not exist. + * @param tokenId uint256 ID of the token being burned + */ + function _burn(uint256 tokenId) internal { + _burn(ownerOf(tokenId), tokenId); + } + + /** + * @dev Internal function to transfer ownership of a given token ID to another address. + * As opposed to transferFrom, this imposes no restrictions on msg.sender. + * @param from current owner of the token + * @param to address to receive the ownership of the given token ID + * @param tokenId uint256 ID of the token to be transferred + */ + function _transferFrom(address from, address to, uint256 tokenId) internal { + require(ownerOf(tokenId) == from, "ERC721: transfer of token that is not own"); + require(to != address(0), "ERC721: transfer to the zero address"); + + _clearApproval(tokenId); + + _ownedTokensCount[from].decrement(); + _ownedTokensCount[to].increment(); + + _tokenOwner[tokenId] = to; + + emit Transfer(from, to, tokenId); + } + + /** + * @dev Internal function to invoke `onERC721Received` on a target address. + * The call is not executed if the target address is not a contract. + * + * This function is deprecated. + * @param from address representing the previous owner of the given token ID + * @param to target address that will receive the tokens + * @param tokenId uint256 ID of the token to be transferred + * @param _data bytes optional data to send along with the call + * @return bool whether the call correctly returned the expected magic value + */ + function _checkOnERC721Received(address from, address to, uint256 tokenId, bytes memory _data) + internal returns (bool) + { + if (!to.isContract()) { + return true; + } + + bytes4 retval = IERC721Receiver(to).onERC721Received(msg.sender, from, tokenId, _data); + return (retval == _ERC721_RECEIVED); + } + + /** + * @dev Private function to clear current approval of a given token ID. + * @param tokenId uint256 ID of the token to be transferred + */ + function _clearApproval(uint256 tokenId) private { + if (_tokenApprovals[tokenId] != address(0)) { + _tokenApprovals[tokenId] = address(0); + } + } +} + +contract MyERC721Card is ERC721{ + + struct Card { + string name; // Name of the Card + uint256 level; // Level of the Card + } + + Card[] public cards; // First Item has Index 0 + address public owner; + + constructor () public { + owner = msg.sender; // owner of MyERC721Card contract who can create a new card + } + + function mintCard(string memory name, address account) public { + require(owner == msg.sender); // Only the Owner can create Items + uint256 cardId = cards.length; // Unique card ID + cards.push(Card(name, 1)); + _mint(account, cardId); // Mint a new card + } + +} +``` + +MyERC721Card.sol`包括一個接口（`IERC165`）、三個庫（`Address`、`SafeMath`和`Counters`）和四個合約（`ERC165`、`IERC721`、`IERC721Receiver`和`MyERC721Card\`）。 + +- IERC165 "接口定義了[ERC-165 規範](https://eips.ethereum.org/EIPS/eip-165) 中描述的接口。 +- 地址 "庫定義了 "isContract "方法，用於測試 "賬戶 "是否為合同。 +- SafeMath "庫定義了 Solidity 算術運算的包裝器，並增加了溢出檢查功能，可安全計算 Solidity 的 "uint256 "類型。 +- 計數器庫定義了只能遞增或遞減一個的計數器。 用於跟蹤發行 ERC721 id 的元素數量。 +- ERC165 "實現了 "IERC165 "接口。 +- IERC721 "定義了[ERC-721 規範](https://eips.ethereum.org/EIPS/eip-721) 中描述的接口，其中還包括 ERC-165。 +- IERC721Receiver 定義了 `onERC721Received` 用於 `MyERC721Card` 合約。 +- ERC721 "實現了 "IERC721 "和 "ERC165"。 +- MyERC721Card "使用 "ERC721 "實現了一種帶有名稱和級別的卡片類型不可篡改令牌，只有 "MyERC721Card "合約的所有者才能鑄造新卡。 + +### 1.2 看看重要的方法 + +讓我們來詳細瞭解一些重要的方法。 + +#### \(1\)ERC721的 "構造函數 "和"_INTERFACE_ID_ERC721"。 + +constructor "會註冊"_INTERFACE_ID_ERC721"，這是一個從 ERC-721 接口導出的 4 字節哈希值，如下所示。 + +```text + /* + * bytes4(keccak256('balanceOf(address)')) == 0x70a08231 + * bytes4(keccak256('ownerOf(uint256)')) == 0x6352211e + * bytes4(keccak256('approve(address,uint256)')) == 0x095ea7b3 + * bytes4(keccak256('getApproved(uint256)')) == 0x081812fc + * bytes4(keccak256('setApprovalForAll(address,bool)')) == 0xa22cb465 + * bytes4(keccak256('isApprovedForAll(address,address)')) == 0xe985e9c + * bytes4(keccak256('transferFrom(address,address,uint256)')) == 0x23b872dd + * bytes4(keccak256('safeTransferFrom(address,address,uint256)')) == 0x42842e0e + * bytes4(keccak256('safeTransferFrom(address,address,uint256,bytes)')) == 0xb88d4fde + * + * => 0x70a08231 ^ 0x6352211e ^ 0x095ea7b3 ^ 0x081812fc ^ + * 0xa22cb465 ^ 0xe985e9c ^ 0x23b872dd ^ 0x42842e0e ^ 0xb88d4fde == 0x80ac58cd + */ + bytes4 private constant _INTERFACE_ID_ERC721 = 0x80ac58cd; + + constructor () public { + // register the supported interfaces to conform to ERC721 via ERC165 + _registerInterface(_INTERFACE_ID_ERC721); + } +``` + +註冊後，當調用 `_INTERFACE_ID_ERC721` 時，ERC-721 和 ERC-165 的 `supportsInterface` 接口會返回 `true`，並告知此合約正在實現 ERC-721 接口。 + +#### \(2\) `function balanceOf(address owner) public view returns (uint256 balance);` + +balanceOf "是ERC-721的強制方法。 `balanceOf` 返回 `owner` 賬戶中的 NFT 數量。 + +```text + function balanceOf(address owner) public view returns (uint256) { + require(owner != address(0), "ERC721: balance query for the zero address"); + + return _ownedTokensCount[owner].current(); + } +``` + +`balanceOf` 只是從 `owner` 在 `ownedTokensCount` 中維護的 `Counter` 對象中返回當前計數。 + +```text + // Mapping from owner to number of owned token + mapping (address => Counters.Counter) private _ownedTokensCount; +``` + +#### \(3\) `safeTransferFrom` 和 `transferFrom` + +這些函數將給定令牌 ID 的所有權轉移到另一個地址。 ERC-721要求使用兩種 "safeTransferFrom "方法，一種包含 "數據"，另一種不包含 "數據"。 除了不帶 `data` 的方法只是將 `data` 設為 `""`，這兩種方法的工作原理完全相同。 `safeTransferFrom` 在調用 `transferFrom` 時會進行更多檢查，如下所示，與 `transferFrom` 相比，"safeTransferFrom "更受歡迎，後者也是 ERC-721 的強制方法。 + +```text + function safeTransferFrom(address from, address to, uint256 tokenId) public { + safeTransferFrom(from, to, tokenId, ""); + } + + function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public { + transferFrom(from, to, tokenId); + require(_checkOnERC721Received(from, to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer"); + } + + function transferFrom(address from, address to, uint256 tokenId) public { + //solhint-disable-next-line max-line-length + require(_isApprovedOrOwner(msg.sender, tokenId), "ERC721: transfer caller is not owner nor approved"); + + _transferFrom(from, to, tokenId); + } +``` + +`safeTransferFrom` 檢查 `to` 地址是否能接收令牌。 `_checkOnERC721Received` 具有驗證邏輯。 如果 `to` 地址是一個合約，則該合約應實現 ERC-721 的 `onERC721Received` 接口，並返回正確的 4 字節哈希值以接收 ERC-721 令牌，如下所示。 + +```text + function _checkOnERC721Received(address from, address to, uint256 tokenId, bytes memory _data) + internal returns (bool) + { + if (!to.isContract()) { + return true; + } + + bytes4 retval = IERC721Receiver(to).onERC721Received(msg.sender, from, tokenId, _data); + return (retval == _ERC721_RECEIVED); + } +``` + +transferFrom "實際上是轉移給定 "tokenId "的所有權，如下所示。 + +```text + function _transferFrom(address from, address to, uint256 tokenId) internal { + require(ownerOf(tokenId) == from, "ERC721: transfer of token that is not own"); + require(to != address(0), "ERC721: transfer to the zero address"); + + _clearApproval(tokenId); + + _ownedTokensCount[from].decrement(); + _ownedTokensCount[to].increment(); + + _tokenOwner[tokenId] = to; + + emit Transfer(from, to, tokenId); + } +``` + +#### \(4\) `function _mint(address to, uint256 tokenId) internal`. + +`_mint` 不是 ERC-721 的一部分。 不過，我們需要一種方法來創建新的 ERC-721 令牌，並在此實現中引入了 `_mint` 來創建新令牌，如下所示。 + +```text + function _mint(address to, uint256 tokenId) internal { + require(to != address(0), "ERC721: mint to the zero address"); + require(!_exists(tokenId), "ERC721: token already minted"); + + _tokenOwner[tokenId] = to; + _ownedTokensCount[to].increment(); + + emit Transfer(address(0), to, tokenId); + } +``` + +`_mint` 是一個內部方法，可在本合同內部調用。 在`MyERC721Card.sol`中，`_mint`僅從`MyERC721Card`合約中的`mintCard`方法調用。 只有智能合約的所有者才能調用 "mintCard"。 + +```text + function mintCard(string name, address account) public { + require(owner == msg.sender); // Only the Owner can create Items + uint256 cardId = cards.length; // Unique card ID + cards.push(Card(name, 1)); + _mint(account, cardId); // Mint a new card + } +``` + +## 2. 部署智能合約 + +你可以使用 Remix Online IDE 或使用 truffle 來部署上述 `MyERC721Card` 智能合約。 + +### 2.1 使用 Remix 在線 IDE 部署智能合約 + +- 請訪問 [Kaia Plugin for Remix](https://ide.kaia.io) 並創建 "MyERC721Card "合同。 完整源代碼見 [Writing ERC-721 Smart Contract](#1-writing-erc-721-smart-contract)。 +- 創建一個賬戶來部署合同。 + - 如果您還沒有賬戶，請在 [https://toolkit.kaia.io/account/accountKeyLegacy](https://toolkit.kaia.io/account/accountKeyLegacy) 上創建一個賬戶。 + - 從水龍頭獲取一些測試 KAIA - [https://faucet.kaia.io](https://faucet.kaia.io) +- 讓我們如下部署 `MyERC721Card.sol`。 + +![ERC721-1-deploy](/img/build/smart-contracts/erc721-1-deploy.png) + +現在，`MyERC721Card` 已上線！ 您可以鑄造和轉移與 ERC-721 兼容的非贗品代幣卡。 + +讓我們為賬戶 "0x2645BA5Be42FeEe907ca8e9d88f6Ee6dAd8c1410 "鑄造兩張卡片，即 "國王 "卡和 "王后 "卡，如下所示。 + +![ERC721-2-mint-king](/img/build/smart-contracts/erc721-2-mint-king.png) ![ERC721-3-mint-queen](/img/build/smart-contracts/erc721-3-mint-queen.png) + +現在我們已經鑄造了兩張卡片，讓我們檢查一下這些 `MyERC721Card` 不可篡改令牌的狀態。 + +![ERC721-4-cards-status](/img/build/smart-contracts/erc721-4-cards-status.png) + +- balanceOf`顯示賬戶`0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410\` 有兩張卡。 +- 參數為 `1` 的 `cards` 顯示令牌 ID 為 `1` 的 `MyERC721Card` 是 1 級的 `Queen` 。 +- 參數 `0` 的 `ownerOf` 顯示令牌 ID `0` 的 `MyERC721Card` 的所有者是 `0x2645BA5Be42FfEe907ca8e9d88f6Ee6dAd8c1410`。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md new file mode 100644 index 000000000000..281dc12c2e98 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/kaiagreeter.md @@ -0,0 +1,46 @@ +# KaiaGreeter + +`KaiaGreeter`是一個返回問候信息的簡單合約。 問候信息在部署合同時設置。 + +## 寫作 KaiaGreeter + +``` +pragma solidity 0.5.6; +contract Mortal { + /* Define variable owner of the type address */ + address payable owner; + /* This function is executed at initialization and sets the owner of the contract */ + constructor () public { owner = msg.sender; } + /* Function to recover the funds on the contract */ + function kill() public { if (msg.sender == owner) selfdestruct(owner); } +} + +contract KaiaGreeter is Mortal { + /* Define variable greeting of the type string */ + string greeting; + /* This runs once when the contract is created */ + constructor (string memory _greeting) public { + greeting = _greeting; + } + /* Main function */ + function greet() public view returns (string memory) { + return greeting; + } +} +``` + +## 使用 Remix 在線集成開發環境部署 KaiaGreeter + +- 請訪問 [Kaia Plugin for Remix](https://ide.kaia.io) 並創建 "KaiaGreeter "合同。 上文提供了完整的源代碼。 +- 準備用於部署合同的賬戶。 + - 如果您還沒有賬戶，請在 [https://toolkit.kaia.io/account/accountKeyLegacy](https://toolkit.kaia.io/account/accountKeyLegacy) 上創建一個賬戶。 + - 從水龍頭獲取一些測試 KAIA - [https://kairos.wallet.kaia.io/faucet](https://kairos.wallet.kaia.io/faucet) +- 部署帶有初始參數（問候語）的合同。 +- 部署完成後，可以在集成開發環境中調用 `greet`。 + +## 參考資料 + +有關合同部署詳情和 Remix Online IDE 使用指南，請參閱以下文件。 + +- [Remix 在線集成開發環境](../../smart-contracts/ide-and-tools/ide-and-tools.md#kaia-ide) +- [部署指南](../deploy/deploy.md) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md new file mode 100644 index 000000000000..615ebe34e111 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/samples/samples.md @@ -0,0 +1,7 @@ +# 合同樣本 + +```mdx-code-block +import DocCardList from '@theme/DocCardList'; + + +``` diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md new file mode 100644 index 000000000000..cc58b8ff8a6a --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/smart-contracts.md @@ -0,0 +1,13 @@ +# 智能合約 + +本節介紹智能合約開發所需的開發資源。 + +為了編寫智能合約，Kaia 目前支持 [Solidity](https://github.com/ethereum/solidity) 作為主要編程語言。 之所以在 Kaia 中採用 Solidity，是因為它是以太坊事實上的標準合約編程語言，擁有龐大的用戶群和活躍的社區。 Kaia 團隊決定為用戶提供熟悉的開發體驗，以便以太坊 DApp 開發人員可以輕鬆嘗試或將其現有智能合約遷移到 Kaia。 + +未來，Kaia 還計劃支持使用其他編程語言編寫智能合約。 Kaia 團隊正在研究開發人員可能接受的各種有利的編程語言。 + +```mdx-code-block +import DocCardList from '@theme/DocCardList'; + + +``` diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md new file mode 100644 index 000000000000..bd7df5458a52 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/solidity-smart-contract-language.md @@ -0,0 +1,137 @@ +# Solidity - 智能合約語言 + +本章只介紹高級概念、開發過程和用 Solidity 編寫的示例，因為 Solidity 在其官方網站上已有詳盡的文檔說明。 有關語言規範或實現，請參閱下面的 [參考文獻](#參考文獻)。 本章內容基於 [參考文獻](#參考文獻）中列出的多個網站。 + +## 堅固和卡婭 + +[Solidity](https://github.com/ethereum/solidity)是一種高級、靜態類型化、面向合約的語言，用於在以太坊平臺上實現智能合約。 雖然 Solidity 最初是為以太坊設計的，但它在編寫智能合約方面具有足夠的通用性；因此，它也可用於其他區塊鏈平臺，如 Kaia。 + +Kaia 正式兼容**倫敦**以太坊虛擬機（EVM）版本。 不保證向後兼容 Kaia 上的其他 EVM 版本。 因此，強烈建議使用 Istanbul 目標選項編譯 Solidity 代碼。 請參閱 [如何設置 Solc 的 EVM 版本](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#setting-the-evm-version-to-target)。 + +:::note + +v1.7.0 協議升級 - 不兼容的更改，包括**伊斯坦布爾**硬分叉項目和 Kaia 自己的項目。 +如果是 Kairos 網絡，則從區塊編號 "#75,373,312 "開始啟用，如果是主網絡，則從區塊編號 "#86,816,005 "開始啟用。 + +v1.7.3 協議升級 - 包括倫敦\*\*\*硬分叉產生的基本費用在內的不兼容變更。 +如果是 Kairos 網絡，則從區塊編號 "#80,295,291 "開始啟用，如果是主網絡，則從區塊編號 "#86,816,005 "開始啟用。 + +v1.8.0 協議升級 - 包括倫敦\*\*\*硬分叉產生的基本費用在內的不兼容變更。 +如果是 Kairos 網絡，則從區塊編號 "#86,513,895 "開始啟用，如果是主網，則從區塊編號 "#86,816,005 "開始啟用。 + +::: + +在為Kaia開發智能合約時，可以使用[Remix](https://remix.ethereum.org/) （一種基於瀏覽器的 IDE）和[Truffle](https://github.com/trufflesuite/truffle) （一種開發框架）等開發工具。 Kaia 團隊將努力保持以太坊開發工具與 Kaia 開發工具之間的兼容性，但在必要時可能會選擇向 Kaia 智能合約開發人員提供這些工具的增強版或更新版。 + +使用 Remix 或 Truffle 開發智能合約非常方便，但 Solidity 編譯器也可在本地使用，只需按照下面網頁中的說明構建或安裝即可： + +- [安裝 Solidity 編譯器](https://docs.soliditylang.org/en/latest/installing-solidity.html) + +請注意，有兩種命令行 Solidity 編譯器： + +- _solc_：全功能編譯器 + - 包含在 Solidity 文檔中 +- _solcjs_：用於 _solc_ 的 Javascript 綁定 + - 作為獨立項目 [solc-js] 維護(https://github.com/ethereum/solc-js) + - _solcjs_ 的命令行選項與 _solc_ 的命令行選項不兼容。 + +其他有助於入門 Solidity 的資料包括以下內容： + +- [頂級穩固性教程](https://medium.com/coinmonks/top-solidity-tutorials-4e7adcacced8) + +## 如何編寫智能合約 + +本節以 Solidity 源代碼為例，讓讀者瞭解智能合約的外觀以及如何編寫合約。 請注意，此處包含的代碼僅供解釋之用，並不用於生產目的。 在代碼中，"(require) "表示任何 Solidity 源文件都需要該行，而"(optional) "則表示不一定需要該行。 符號 `Ln:` 並非 Solidity 代碼的一部分，在此加入只是為了顯示行號。 請不要在實際使用的源代碼中使用這些符號。 + +```text +L01: pragma solidity 0.5.12; // (required) version pragma +L02: +L03: import "filename"; // (optional) importing other source files +L04: +L05: // (optional) smart contract definition +L06: contract UserStorage { +L07: mapping(address => uint) userData; // state variable +L08: +L09: function set(uint x) public { +L10: userData[msg.sender] = x; +L11: } +L12: +L13: function get() public view returns (uint) { +L14: return userData[msg.sender]; +L15: } +L16: +L17: function getUserData(address user) public view returns (uint) { +L18: return userData[user]; +L19: } +L20: } +``` + +上述代碼不言自明，因此熟悉其他編程語言的人可以跳過本節的解釋，直接跳到下一節。 不過，對於那些不清楚代碼作用的人，或者對於 Solidity 是第一種編程語言的人，我們會在下面附上源代碼的簡短說明： + +- 代碼中以雙斜線開頭的部分是註釋，而不是代碼；它們用於註釋和解釋代碼。 編譯器會忽略註釋。 +- L01 "中的 "pragma "語句表示編譯器的最小版本。 +- L03`中的`import` 語句從"`filename\`"導入所有全局符號。 文件名 "應為實際文件名。 +- `L05` - `L20` 定義了一個名為 `UserStorage` 的智能合約。 關鍵字 `contract` 位於合約名稱之前，聲明代碼代表一個智能合約。 Solidity 中的契約類似於面嚮對象語言中的類。 每個合約可包含狀態變量、函數、函數修改器、事件、結構類型和枚舉類型的聲明。 此外，合同還可以繼承其他合同。 示例代碼包含一個合同定義，但一個 Solidity 文件可能包含多個合同定義。 +- 在`L07`中，`userData`是映射類型的狀態變量。 狀態變量永久保存在合約存儲器中。 狀態變量 `userData` 維護著 `address` 和 `uint` 值之間的映射。 地址 "類型保存一個 20 字節的地址（Kaia 使用的 20 字節地址與以太坊類似）。 +- `L09` 定義了一個公共函數 `set`，用於在 `userData` 中保存信息發送者的 `x` 值。 變量 "msg.sender "是 Solidity 中定義的一個特殊變量，表示消息（即當前呼叫）發送者的地址。 關鍵字 "public "表示該函數是合約接口的一部分，可在外部或內部調用。 +- L13`中的函數`get` 和 L17` 中的函數 `getUserData` 是用 `view` 聲明的，這意味著函數承諾不修改任何狀態變量。 它們的聲明包括 `returns (uint)`，這意味著它們返回一個 `uint` 值。 + +有關 Solidity 語言語法和語義的更多信息，請參閱 [Solidity 文檔](https://docs.soliditylang.org/)。 + +## 如何編譯、部署和執行 + +編譯 Solidity 代碼的一種方法是使用命令行編譯器 _solc_。 這種編譯器可以產生各種輸出，從簡單的二進制文件和彙編到抽象語法樹（parse tree\ ）。 假設上面的代碼保存在 `UserStorage.sol`（上面顯示的源文件中不包括 `L03`），編譯文件 `UserStorage.sol`的一些示例如下。 + +```bash +$ solc --bin UserStorage.sol +``` + +- 該命令將以二進制_即_字節碼_的形式打印編譯輸出。 + +```bash +solc -o output --bin --ast --asm UserStorage.sol +``` + +- 編譯器會生成二進制文件、抽象語法樹和彙編代碼，並將它們作為單獨的文件存放在 "輸出 "目錄下。 + +```bash +solc --optimize --bin UserStorage.sol +``` + +- 為提高性能，可在編譯過程中使用 `--optimize` 標記激活優化器。 + +下面列出了一些用於編譯、部署和執行智能合約的資源。 + +- [使用Solidity命令行編譯器](https://docs.soliditylang.org/en/latest/using-the-compiler.html) +- [使用 Remix 編譯合同](https://remix-ide.readthedocs.io/en/stable/compile.html) +- [Running transactions with Remix](https://remix-ide.readthedocs.io/en/stable/run.html) +- [Remix Learneth 教程](https://remix-ide.readthedocs.io/en/latest/remix_tutorials_learneth.html) +- [用 Truffle 編譯合同](https://trufflesuite.com/docs/truffle/getting-started/compiling-contracts) +- [使用 Truffle 部署合同](https://trufflesuite.com/docs/truffle/getting-started/running-migrations) + +注：本部分內容今後將進行更新。 + +## 調試智能合約 + +由於缺乏成熟的調試工具，調試 Solidity 代碼比調試用其他編程語言編寫的代碼更加困難。 下面，我們列出了一些用於 Solidity 調試的資源。 + +- [使用 Remix 調試交易](https://remix-ide.readthedocs.io/en/latest/debugger.html) +- [使用 Remix 調試事務的教程](https://remix-ide.readthedocs.io/en/latest/tutorial_debug.html) +- [使用 Truffle 調試合同](https://trufflesuite.com/docs/truffle/getting-started/using-the-truffle-debugger/) + +注：本部分內容今後將進行更新。 + +## 智能合約最佳實踐 + +要消除智能合約中的安全問題和代碼質量問題，必須學習並遵循 Solidity 編程的最佳實踐。 在此，我們展示了 Solidity 最佳實踐的參考資料。 + +- [智能合約安全最佳實踐](https://github.com/ConsenSys/smart-contract-best-practices) + +注：本部分內容今後將進行更新。 + +## 參考資料 + +- [Solidity GitHub 頁面](https://github.com/ethereum/solidity) +- [Solidity文檔](https://solidity.readthedocs.io/en/latest/index.html) +- [混音文檔](https://remix-ide.readthedocs.io/en/latest/) +- [松露文檔](https://trufflesuite.com/docs/truffle/) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md new file mode 100644 index 000000000000..bc6ae30cba28 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/testing-guide.md @@ -0,0 +1,261 @@ +# 測試智能合約 + +在本節中，我們將介紹如何測試智能合約。 由於區塊鏈上的任何交易都是不可逆轉的，因此在部署智能合約之前對其進行測試至關重要。 + +## 使用松露進行測試 + +Truffle 提供了一個自動測試框架。 該框架可讓您以兩種不同的方式編寫簡單、易於管理的測試： + +- 在 "Javascript "和 "TypeScript "中，用於從外部世界執行您的合約，就像應用程序一樣。 +- 在 "Solidity "中，用於在預付款、裸機情況下執行合同。 + +### 1. 入門 + +我們將按照[使用 Truffle 的部署指南](./deploy/deploy.md#truffle)創建合約並進行部署。 不過，在部署之前，我們將在合約中添加一個設置函數 `setGreet` 以進行測試。 源代碼如下。 + +**注：** 我們對測試合同做了一些修改。 + +以下是 KaiaGreeting 合同源代碼。 + +``` +pragma solidity 0.5.6; + +contract Mortal { + /* Define variable owner of the type address */ + address payable owner; + /* This function is executed at initialization and sets the owner of the contract */ + constructor () public { owner = msg.sender; } + /* Function to recover the funds on the contract */ + function kill() public payable { if (msg.sender == owner) selfdestruct(owner); } +} + +contract KaiaGreeter is Mortal { + /* Define variable greeting of the type string */ + string greeting; + + /* This runs when the contract is executed */ + constructor (string memory _greeting) public { + greeting = _greeting; + } + + /* Main function */ + function greet() public view returns (string memory) { + return greeting; + } + + /* Newly added function for testing. */ + function setGreet(string memory _greeting) public { + // only owner can change greeting message + require(msg.sender == owner, "Only owner is allowed."); + greeting = _greeting; + } +} +``` + +我們將測試 1) `greet()`函數是否能正確返回 "Hello, Kaia "信息，2) `setGreet()`函數是否能正確設置新的問候語信息，並在非所有者賬戶嘗試更新問候語時進行還原。 + +首先，我們將為通用斷言安裝 Chai 斷言庫（或你使用的任何其他斷言庫），為智能合約斷言安裝 truffle 斷言庫。 + +``` +npm install --save-dev chai truffle-assertions +``` + +### 2. 在 Solidity 中編寫測試 + +使用 Solidity 進行測試比 JavaScript 測試更直觀。 Solidity 測試合同作為 .sol 文件與 JavaScript 測試並存。 + +在 "test "文件夾中創建名為 "TestKaiaGreeting.sol "的文件。 Truffle 套件為我們提供了用於測試的輔助庫，因此我們需要導入這些庫。 讓我們來看看 Solidity 測試的示例： + +``` +pragma solidity ^0.5.6; + +import "truffle/Assert.sol"; +import "truffle/DeployedAddresses.sol"; +import "../contracts/HashMarket.sol"; +``` + +- Assert ：它允許我們訪問各種測試函數，如`Assert.equals()`、`Assert.g greaterThan()`等。 +- 部署地址（DeployedAddresses）：每次更改合同時，都必須將其重新部署到新地址。 您可以通過該庫獲取已部署的合同地址。 + +現在，讓我們編寫一段測試代碼。 + +``` +pragma solidity ^0.5.6; + +import "truffle/Assert.sol"; +import "truffle/DeployedAddresses.sol"; +import "../contracts/KaiaGreeter.sol"; + +contract TestKaiaGreeter { + + function testGreetingMessage() public { + // DeployedAddresses.KaiaGreeter() handles contract address. + KaiaGreeter greeter = KaiaGreeter(DeployedAddresses.KaiaGreeter()); + + string memory expectedGreet = "Hello Kaia"; + + string memory greet = greeter.greet(); + + Assert.equal(greet, expectedGreet, "greeting message should match"); + } +} +``` + +運行 Solidity 測試代碼 + +``` +$ truffle test +# Output +Using network 'development'. + + +Compiling your contracts... +=========================== +> Compiling ./test/TestKaiaGreeter.sol + + + + TestKaiaGreeter + 1) testGreetingMessage + + Events emitted during test: + --------------------------- + + + --------------------------- + + + 0 passing (5s) + 1 failing + + 1) TestKaiaGreeter + testGreetingMessage: + Error: greeting message should match (Tested: Hello, Kaia, Against: Hello Kaia) + at result.logs.forEach.log (/Users/jieunkim/.nvm/versions/node/v10.16.0/lib/node_modules/truffle/build/webpack:/packages/core/lib/testing/soliditytest.js:71:1) + at Array.forEach () + at processResult (/Users/jieunkim/.nvm/versions/node/v10.16.0/lib/node_modules/truffle/build/webpack:/packages/core/lib/testing/soliditytest.js:69:1) + at process._tickCallback (internal/process/next_tick.js:68:7) +``` + +哎呀，我們失敗了。 讓我們檢查一下錯誤信息，"Error: greeting message should match (Tested: Hello, Kaia, Against: Hello Kaia)"。 我注意到 _string memory expectedGreet = "Hello Kaia"_.\ +處漏掉了"'',(逗號)'\`"，請修改代碼並再次運行測試。 + +``` +$ truffle test +# Output +Using network 'development'. + + +Compiling your contracts... +=========================== +> Compiling ./test/TestKaiaGreeter.sol + + + + TestKaiaGreeter + ✓ testGreetingMessage (58ms) + + + 1 passing (5s) +``` + +祝賀你 您的測試已通過。 + +### 3. 用 JavaScript 編寫測試 + +Truffle 使用 [Mocha](https://mochajs.org/) 測試框架和 [Chai](https://www.chaijs.com/) 斷言庫，為 JavaScript 測試提供了一個堅實的框架。 JavaScript 測試為您提供了更大的靈活性，使您能夠編寫更復雜的測試。 + +讓我們在`test`目錄下創建一個文件並命名為`0_KaiaGreeting.js`。 + +測試代碼是 + +```javascript +// Interacting directly with KaiaGreeter contract +const KaiaGreeter = artifacts.require("./KaiaGreeter.sol"); +const truffleAssert = require('truffle-assertions'); + +contract("KaiaGreeter", async(accounts) => { + // store the contract instance at a higher level + // to enable access from all functions. + var klaytnGreeterInstance; + var owner = accounts[0]; + var greetMsg = "Hello, Kaia"; + + // This will run before each test proceed. + before(async function() { + // set contract instance into a variable + klaytnGreeterInstance = await KaiaGreeter.new(greetMsg, {from:owner}); + }) + + it("#1 check Greeting message", async function() { + // set the expected greeting message + var expectedGreeting = greetMsg; + var greet= await klaytnGreeterInstance.greet(); + assert.equal(expectedGreeting, greet, "greeting message should match"); + + }) + + it("#2 update greeting message.", async function() { + var newGreeting = "Hi, Kaia"; + + await klaytnGreeterInstance.setGreet(newGreeting, { from:owner }); + var greet = await klaytnGreeterInstance.greet(); + assert.equal(newGreeting, greet, "greeting message should match"); + }); + + it("#3 [Failure test] Only owner can change greeting.", async function() { + var fakeOwner = accounts[1]; + await truffleAssert.fails(klaytnGreeterInstance.setGreet(greetMsg, { from:fakeOwner })); + }); +}); +``` + +如果您不熟悉 "Mocha "單元測試，請查閱[Mocha 文檔](https://mochajs.org/#getting-started)。 + +- 使用 `contract()` 代替 `describe()` + + 從結構上看，Truffle 測試代碼應該與 Mocha 的常規測試代碼沒有太大區別。 您的測試應包含能被 Mocha 識別為自動測試的代碼。 Mocha 和 Truffle 測試的區別在於 contract() 函數。 + + **注意**使用`contract()`函數和`accounts`數組來指定可用的 Kaia 賬戶。 +- 測試中的合同抽象 + + 由於 Truffle 無法檢測測試過程中需要與哪個合約交互，因此應明確指定合約。 一種方法是使用 `artifacts.require()` 方法。 +- it "語法 + + 這表示每個測試用例的描述。 說明將在試運行時打印在控制檯上。 +- truffle-assertion\` 庫 + + 通過提供 `truffleAssert.reverts()` 和 `truffleAssert.fails()` 函數，該庫可讓您輕鬆測試還原或其他失敗。 + +輸出結果如下 + +``` +Using network 'development'. + + +Compiling your contracts... +=========================== +> Everything is up to date, there is nothing to compile. + + + + Contract: KaiaGreeter + ✓ #1 check Greeting message + ✓ #2 update greeting message. (46ms) + ✓ #3 [Failure test] Only owner can change greeting. + + + 3 passing (158ms) +``` + +祝賀你 您的測試已通過。 + +### 4. 指定測試 + +您可以選擇要執行的測試文件。 + +``` +truffle test ./test/0_KaiaGreeting.js +``` + +詳情請查看 [Truffle 測試](https://www.trufflesuite.com/docs/truffle/testing/testing-your-contracts) 和 [Truffle 命令](https://www.trufflesuite.com/docs/truffle/reference/truffle-commands#test)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md new file mode 100644 index 000000000000..c2e948f2c44c --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/token-standard.md @@ -0,0 +1,138 @@ +# Kaia 兼容代幣（KCT） + +Kaia Compatible Token（KCT）是一種特殊類型的智能合約，它實現了某些技術規範。 每個想在 Kaia 上發行代幣的人都必須遵守規範。 + +Kaia 中定義了令牌標準，如 [KIP-7](https://kips.kaia.io/KIPs/kip-7) 和 [KIP-17](https://kips.kaia.io/KIPs/kip-17)。 + +還可以定義其他 KCT，以滿足某些技術規格。 如果有人需要其他令牌標準，請訪問 [Kaia Improvement Proposal](https://github.com/kaiachain/KIPs)，提出新的令牌標準。 + +## 可摺疊令牌標準（KIP-7） + +可變代幣是具有均勻性和可分割性的代幣。 每個可替代代幣都可以互換，因為每個單位的代幣都具有相同的價值。 就像每張一元紙幣都有一元的價值一樣。 在大多數情況下，可替代性是加密貨幣的基本特徵，因此大部分區塊鏈代幣都是可替代代幣。 + +要通過智能合約實現這些屬性，可以使用 KIP-7 令牌標準。 與 KIP-7 兼容的令牌實現了以下接口。 請注意，[KIP-13](https://kips.kaia.io/KIPs/kip-13) 必須同時執行。 對於錢包應用，可執行 [錢包接口](https://kips.kaia.io/KIPs/kip-7#wallet-interface)。 + +```solidity +// IKIP7 +event Transfer(address indexed from, address indexed to, uint256 value); +event Approval(address indexed owner, address indexed spender, uint256 value); + +function totalSupply() external view returns (uint256); +function balanceOf(address account) external view returns (uint256); +function transfer(address recipient, uint256 amount) external returns (bool); +function allowance(address owner, address spender) external view returns (uint256); +function approve(address spender, uint256 amount) external returns (bool); +function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); +function safeTransfer(address recipient, uint256 amount, bytes data) external; +function safeTransfer(address recipient, uint256 amount) external; +function safeTransferFrom(address sender, address recipient, uint256 amount, bytes data) external; +function safeTransferFrom(address sender, address recipient, uint256 amount) external; + +// IKIP7Metadata (optional) +function name() external view returns (string memory); +function symbol() external view returns (string memory); +function decimals() external view returns (uint8); + +// IKIP7Mintable (optional) +function mint(address _to, uint256 _amount) external returns (bool); +function isMinter(address _account) external view returns (bool); +function addMinter(address _account) external; +function renounceMinter() external; + +// IKIP7Burnable (optional) +function burn(uint256 _amount) external; +function burnFrom(address _account, uint256 _amount) external; + +// IKIP7Pausable (optional) +event Paused(address _account); +event Unpaused(address _account); + +function paused() external view returns (bool); +function pause() external; +function unpause() external; +function isPauser(address _account) external view returns (bool); +function addPauser(address _account) external; +function renouncePauser() external; +``` + +在上述界面的基礎上，開發者可以通過添加新功能和邏輯來定製令牌，並將其部署到 Kaia 網絡上。 + +更多信息，請參閱官方 [KIP-7 文檔](https://kips.kaia.io/KIPs/kip-7)。 + +- 實施示例見 [https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP7/KIP7.sol](https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP7/KIP7.sol)。 + +## Non-fungible Token Standard\(KIP-17\) + +Non-fungible token\(NFT\) 是一種特殊類型的代幣，代表一種獨特的資產。 正如 "不可篡改 "這個名字所暗示的，每一個代幣都是獨一無二、不可分割的。 不可篡改令牌的這種獨特性為資產數字化開闢了新天地。 例如，它可以用來表示數字藝術、遊戲物品或任何類型的獨特資產，並允許人們進行交易。 + +例如，區塊鏈收集遊戲[Cryptokitties](https://www.cryptokitties.co/)實現了不可篡改的代幣，以代表具有不同遺傳信息的不同小貓。 每隻小貓都是獨一無二的，不可互換，因此不同的小貓代幣有不同的價值。 + +要實現不可篡改令牌，可以使用 [KIP-17](https://kips.kaia.io/KIPs/kip-17)。 KIP-17 令牌合約執行以下接口。 請注意，[KIP-13](https://kips.kaia.io/KIPs/kip-13) 必須同時執行。 對於錢包應用，可執行 [錢包接口](https://kips.kaia.io/KIPs/kip-17#wallet-interface)。 + +```solidity +// IKIP17 +event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); +event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); +event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); + +function balanceOf(address _owner) external view returns (uint256); +function ownerOf(uint256 _tokenId) external view returns (address); +function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes _data) external payable; +function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; +function transferFrom(address _from, address _to, uint256 _tokenId) external payable; +function approve(address _approved, uint256 _tokenId) external payable; +function setApprovalForAll(address _operator, bool _approved) external; +function getApproved(uint256 _tokenId) external view returns (address); +function isApprovedForAll(address _owner, address _operator) external view returns (bool); + +// IKIP17Metadata (optional) +function name() external view returns (string _name); +function symbol() external view returns (string _symbol); +function tokenURI(uint256 _tokenId) external view returns (string); + +// IKIP17Enumerable (optional) +function totalSupply() external view returns (uint256); +function tokenByIndex(uint256 _index) external view returns (uint256); +function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256); + +// IKIP17Mintable (optional) +function mint(address _to, uint256 _tokenId) public returns (bool); +function isMinter(address _account) public view returns (bool); +function addMinter(address _account) public; +function renounceMinter() public; + +// IKIP17MetadataMintable (optional) +function mintWithTokenURI(address _to, uint256 _tokenId, string memory _tokenURI) public returns (bool); +function isMinter(address _account) public view returns (bool); +function addMinter(address _account) public; +function renounceMinter() public; + +// IKIP17Burnable (optional) +function burn(uint256 _tokenId) public; + +// IKIP17Pausable (optional) +event Paused(address _account); +event Unpaused(address _account); +function paused() public view returns (bool); +function pause() public; +function unpause() public; +function isPauser(address _account) public view returns (bool); +function addPauser(address _account) public; +function renouncePauser() public; +``` + +在上述界面的基礎上，開發者可以通過添加新功能和邏輯來定製令牌，並將其部署到 Kaia 網絡上。 + +更多信息，請參閱官方 [KIP-17 文檔](https://kips.kaia.io/KIPs/kip-17)。 + +- 實施示例見 [https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP17/KIP17.sol](https://github.com/kaiachain/kaia-contracts/blob/main/contracts/KIP/token/KIP17/KIP17.sol)。 + +## Kaia 服務鏈的令牌標準 + +服務鏈指的是錨定 Kaia 主區塊鏈網絡的 Kaia 側鏈。 在實施服務鏈時，要使用特殊類型的合同來支持主鏈和服務鏈之間的價值轉移。 這些合約目前正在開發中，一旦準備就緒，Kaia 服務鏈的令牌規格將在 KaiaDocs 上提供。 + +## 關於 ERC-20 和 ERC-721 的說明 + +由於 Kaia 發佈了 KIP-7 和 KIP-17 作為其代幣標準，因此建議分別根據 KIP-7 和 KIP-17 執行可替換和不可替換代幣合約，而不是遵循 ERC-20 和 ERC-721。 +KIP-7 和 KIP-17 基於 ERC-20 和 ERC-721，但它們是為 Kaia 量身定製的，因此更適合 Kaia 生態系統。 儘管 Kaia 網絡仍然支持 ERC-20 和 ERC-721，但它們可能與 Kaia 生態系統中的各種工具不兼容。 +有關令牌標準差異的更多信息，請訪問 [KIP-7](https://kips.kaia.io/KIPs/kip-7#differences-with-erc-20) 和 [KIP-17](https://kips.kaia.io/KIPs/kip-17#differences-from-erc-721)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md new file mode 100644 index 000000000000..54d570b8f790 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/block-explorers.md @@ -0,0 +1,248 @@ +--- +sidebar_label: 使用積木探索器 +--- + +# 如何使用區塊探索器驗證智能合約 + +## 導言 + +通常情況下，智能合約的部署者是唯一能接觸到實際部署代碼的一方，在部署者驗證之前，公眾無法讀取合約的源代碼。 然而，這正是合約驗證作為智能合約開發週期中一個重要步驟的作用所在，因為它有助於提高已部署合約的透明度（對用戶而言）、便利性（對開發者而言）和安全性。 + +儘管如此，一旦智能合約得到驗證，Kaiascope 和 Kaiascan 等區塊探索器還可以讓公眾使用區塊探索器的用戶界面與合約的公共方法進行交互。 除此之外，公眾還可以直接訪問經過驗證的合同源代碼。 + +在本指南中，我們將瞭解如何使用區塊探索器驗證 Kaia 網絡上部署的智能合約。 + +## 先決條件 + +- [Remix IDE](https://ide.kaia.io/)和[Kaia 錢包](https://docs.kaiawallet.io/getting_started/quick_start#install-kaia-wallet) +- 從 [水龍頭](https://faucet.kaia.io) 測試 KAIA 是否足夠 + +## 開始 + +在本指南中，我們將介紹在 Kaia 生態系統中存在的區塊探索器上驗證單個合約和多部分合約的方法，這些探索器是： + +- [Kaiascope](https://kaiascope.com/) +- [Kaiascan](https://www.kaiascan.io/) + +廢話不多說，讓我們開始吧！ + +## 部署單一合同 + +要驗證智能合約，首先需要在目標網絡上部署合約。 因此，在本指南中，我們將把合同部署到 Kaia Kairos Testnet。 此外，在本教程中，我們將在 Remix IDE 上部署一個名為 "Counter.sol "的簡單計數器合約。 代碼如下所示： + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; +contract Counter { + uint256 public count; + constructor(uint256 _initialCount) { + count = _initialCount; + } + function incrementCounter() public { + count++; + } + function decrementCounter() public { + count--; + } + function resetCounter() public { + count = 0; + } +} +``` + +:::note + +您可以在此頁面查看 Kaia Kairos Testnet 上使用 [libaries](../../../references/sdk/sdk.md)部署智能合約的教程。 您也可以使用 [Hardhat](../../get-started/hardhat.md), [Foundry](../deploy/foundry.md), [Remix](../deploy/deploy.md#remix-ide) 等開發工具或其他工具，將智能合約部署到 Kaia Kairos Testnet。 + +::: + +## 單一合同核查參數 + +在區塊探索器上驗證合約需要一些參數，在部署智能合約時必須考慮這些參數。 以下是與合同編譯器和部署有關的一些細節，以便成功驗證合同： + +Remix IDE : + +- 在 Remix IDE 上，導航至**Solidity 編譯器選項卡**。 + + - 觀察用於編譯和部署合同的 \*\* 編譯器版本\*\*。 + - 注意合同中使用的**開源許可類型**。 這意味著在 Solidity 源文件開頭使用的 SPDX 許可證標識符。 在 `Counter.sol` 文件中，我們使用了 `// SPDX-License-Identifier：MIT` + - 注意用於部署合同的 **EVM 版本**。 + - (可選）如果在編譯過程中啟用了**優化**，請注意優化運行參數的值 + + ![](/img/build/tutorials/counter-veri-parameters.png) + +- 在 Remix IDE 上，導航至 **Kaia 選項卡**。 + + - (可選） 如果合約構造函數方法接受參數，請注意構造函數參數的[ABI-編碼形式](https://docs.soliditylang.org/en/develop/abi-spec.html) + - 成功部署後，在**已部署合約**選項卡上記下智能合約的合約地址。 + + ![](/img/build/tutorials/counter-veri-parametersII.png) + +## 部署多部分合同 + +值得注意的是，部署多部分合同的步驟與部署單部分合同的步驟相同。 在本指南中，我們將部署一個名為 `airdropToken.sol` 的簡單 KIP7 空投合約。 代碼如下所示： + +```solidity +//SPDX-License-Identifier: MIT +pragma solidity ^0.8.4; +import "@kaiachain/contracts/KIP/token/KIP7/KIP7.sol"; +import "@kaiachain/contracts/access/Ownable.sol"; +// the creator of the project mints certian amount of fungible tokens directly to a certain selection of wallets. +contract TokenAirdrop is KIP7, Ownable { + constructor() KIP7("Token Aidrop Demo", "TAD") { + } + // Airdrop Token + function airdropTokens(address[] calldata wAddresses, uint[] calldata tAmount) public onlyOwner { + require(wAddresses.length == tAmount.length, "Must be same lenght"); + for (uint256 i = 0; i < wAddresses.length; i++) { + _mintSingleTokens(wAddresses[i], tAmount[i]); + } + } + function _mintSingleTokens(address wAddress, uint amount) private { + _mint(wAddress, amount); + } + function supportsInterface(bytes4 interfaceId) + public + view + virtual + override + returns (bool) + { + return + super.supportsInterface(interfaceId); + } +} +``` + +## 多部分合同核查參數 + +驗證多部分合同的參數與驗證單部分合同的參數相同。 但是，由於它們是由多個從屬合同組成的，我們需要將合同的所有從屬關係預處理成一個單一的 solidity 文件。 這種預處理通常被稱為智能合約扁平化。 + +因此，我們必須將合約扁平化，以便在區塊資源管理器上使用新的扁平化 Solidity 文件進行驗證。 + +Remix IDE: + +- 在 Remix IDE 上，導航至**文件資源管理器選項卡**。 + + - 在**合同**文件夾下選擇新創建的合同 + - 點擊或用雙指輕點，即可查看合同上的所有可用命令。 + - 選擇 \*\* 壓平\*\* + + ![](/img/build/tutorials/airdropToken-flattened.png) + + - 一旦代碼被扁平化，你將看到一個名為 `airdropTokens_flattened.sol` 的新合約。 + + ![](/img/build/tutorials/airdropToken-flattened-file.png) + +:::note + +有不同的工具可以將多部分智能合約扁平化為一個單一的 Solidity 文件，如 [Hardhat Flattener](https://hardhat.org/hardhat-runner/docs/advanced/flattening)。 請參閱相關智能合約扁平化工具的文檔，瞭解更詳細的使用說明。 + +::: + +## 核實合同 + +在獲得所有驗證參數後，我們將在本節中詳細介紹在區塊資源管理器上驗證單一智能合約（Counter.sol）和多部分智能合約（airdropTokens.sol）的步驟。 + +### 1. Kaiascope + +要在 Kaiascope 上驗證單份合同和多份合同，請按以下步驟操作： + +#### 1.1 驗證單一合同 + +1. 進入 [Kaiascope](https://kairos.kaiascope.com)的搜索欄，粘貼已部署的合同地址。 +2. 導航至該頁面上的**合同選項卡**。 +3. 單擊**匹配合同源代碼**鏈接，提交合同代碼以供驗證。 + +![](/img/build/tutorials/counter-contract-tab.png) + +4. 在合同驗證頁面，確保您的賬戶已連接到 Kaia 錢包或 Metamask。 在本指南中，我們將使用 Kaia 錢包。 +5. 在**合同地址欄**中填寫合同地址。 注：該字段通常會自動填寫合同地址。 +6. 選擇 "Counter.sol "示例使用的**編譯器版本**。 +7. 選擇用於 "Counter.sol "示例的**開源許可類型**。 在 "Counter.sol "示例中，選擇 "**MIT License (MIT)**" 選項。 如果沒有使用許可證，請選擇 **無許可證（無）**。 +8. 在**源代碼字段**中，選擇**源文本**，然後在文本字段中粘貼 "Counter.sol "的源代碼。 +9. 如果在編譯過程中啟用了**優化**，則為**優化**選擇**真**，並在**優化運行**下填寫運行次數為**200**。 +10. 為合同選擇 **EVM 版本**。 以 "Counter.sol "為例，選擇 "**伊斯坦布爾**"選項。 +11. 點擊底部的驗證碼和**簽名並提交**按鈕，確認並開始驗證。 + +![](/img/build/tutorials/counter-verification-page.png) + +12. 簽署驗證請求後，您將收到驗證狀態通知 + +![](/img/build/tutorials/counter-success-popup.png) + +13. 驗證完成後，瀏覽器將顯示驗證結果，並顯示包含合同地址的成功結果頁面。 點擊合同地址，查看**合同源代碼**、**合同 ABI**和**字節碼**。 + +![](/img/build/tutorials/counter-success-popup-I.png) + +![](/img/build/tutorials/counter-full-verification.png) + +#### 1.2 驗證多部分合同 + +在 Kaiascope 上驗證多部分合同與驗證單部分合同一樣簡單，只是需要一些額外的步驟。 在本節中，我們將通過以下額外步驟驗證 `airdropToken.sol` 合約： + +- 您可以在**源代碼**下選擇**源文本**（Counter.sol 示例的第 3 步），或在**源代碼**字段下選擇**合併文件**。 在**源文本**的情況下，複製 "airdropToken_flattened.sol "中的代碼並將其粘貼到文本字段中。 如果**固化文件**，可在 Remix IDE 上下載`airdropToken_flattened.sol`文件並上傳到字段。 + +a. 來源文本 + +![](/img/build/tutorials/airdrop-veri-field-I.png) + +b. 固體文件 + +![](/img/build/tutorials/airdrop-veri-field-II.png) + +在此之後，其他所有步驟都與驗證單個合同相同。 填寫驗證參數後，點擊**簽署並提交**按鈕進行確認並開始驗證。 + +驗證完成後，瀏覽器將顯示驗證結果，並顯示包含合同地址的成功結果頁面。 點擊合同地址，查看**合同源代碼**、**合同 ABI**和**字節碼**。 + +![](/img/build/tutorials/airdrop-success-popup.png) + +![](/img/build/tutorials/airdrop-success-popup-I.png) + +![](/img/build/tutorials/airdrop-full-verification.png) + +### 2. Kaiascan + +要在 Kaiascan 上驗證單個合同和多部分合同，請瀏覽[合同提交申請頁面](https://kairos.kaiascan.io/contract)。 + +:::note + +目前，Kaiascan 上的合同驗證還處於測試階段。 + +::: + +![](/img/build/tutorials/kaiascan-con-sub-page.png) + +#### 2.1 核查單一合同 + +1. 填寫已部署合同的**合同地址** (Counter.sol) +2. 選擇 "Counter.sol "示例使用的**編譯器版本** +3. 選擇用於 "Counter.sol "示例的**開源許可類型**。 在 "Counter.sol "示例中，選擇 "**MIT License (MIT)**" 選項。 如果沒有使用，請選擇 **無許可證（無）** +4. 確保從 Remix IDE 下載 "Counter.sol"，並將其上載到\*\*源代碼（Solidity 文件）\*\*字段中。 +5. 為合同選擇 **EVM 版本**。 以 "Counter.sol "為例，選擇 "**伊斯坦布爾**"選項。 +6. 如果在編譯過程中啟用了**優化**，則為**優化**選擇**真**，並在**優化運行**下填寫運行次數為**200**。 +7. (可選）要獲取該字段的 ABI 編碼構造函數參數，請訪問 [abi.hashex.org](http://abi.hashex.org)，獲取下圖所示的編碼數據： + +![](/img/build/tutorials/abi-hashex.png) + +8. 點擊**驗證和發佈**按鈕開始驗證。 + +![](/img/build/tutorials/counter-k-verification-page.png) + +9. 驗證完成後，您將收到**提交成功**信息。 現在，您可以在資源管理器搜索欄中粘貼合同地址，查看**合同源代碼**、**合同 ABI**、**創建代碼**和**ABI 編碼值**。 + +> ![](/img/build/tutorials/counter-k-full-verification.png) + +### 2.2 驗證多部分合同 + +在 Kaiascan 驗證多部分合同的步驟與驗證單個合同相同。 不過，需要注意的是，由於 Kaiascan 目前不支持上傳文件進行驗證，我們將在**下面輸入 Solidity 合同代碼**字段中複製並粘貼 "airdropToken_flattened.sol "文件。 + +![](/img/build/tutorials/airdrop-k-verification-page.png) + +填寫驗證參數後，點擊**驗證和發佈**按鈕開始驗證。 驗證完成後，驗證頁面將刷新。 現在，您可以在資源管理器搜索欄中粘貼合同地址，查看**合同源代碼**、**合同 ABI**和**創建代碼**。 + +![](/img/build/tutorials/airdrop-k-full-verification.png) + +## 結論 + +恭喜您遵循本指南！ 在本教程中，您將學習如何使用 Kaiascope 和 Kaiascan 來驗證合同（單部分和多部分），以提高部署合同的透明度（對用戶）、便利性（對開發人員）和安全性。 如需瞭解更多信息，請訪問 [Kaia 文檔](https://docs.kaia.io/)；如有任何問題，請訪問 [Kaia 論壇](https://devforum.kaia.io/)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md new file mode 100644 index 000000000000..c607c7cd4391 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.md @@ -0,0 +1,88 @@ +--- +sidebar_label: 使用硬頭盔 +--- + +# 如何使用 Hardhat 驗證智能合約 + +本指南允許您使用Hardhat Verify Plugin直接從 CLI 在 Kaiascope 上自動驗證智能合約的源代碼。 + +要在 klaytn 上驗證您的合同，您需要在`hardhat.config.js`中添加以下配置： + +## 主網 + +``` +module.exports = { + networks：{ + kaia: { + chainId：8217, + url："RPC_URL", + }, + }, + etherscan：{ + apiKey：{ + kaia: "unnecessary", + }, + customChains：[ + { + network："kaia", + chainId：8217, + urls：{ + apiURL："https://api-cypress.klaytnscope.com/api", + browserURL："https://kaiascope.com/", + }, + }, + ]。 + } +} + +``` + +## Kairos + +``` +module.exports = { + networks: { + kairos: { + chainId: 1001, + url: "RPC_URL", + }, + }, + etherscan: { + apiKey: { + kairos: "unnecessary", + }, + customChains: [ + { + network: "kairos", + chainId: 1001, + urls: { + apiURL: "https://api-baobab.klaytnscope.com/api", + browserURL: "https://kairos.kaiascope.com", + }, + }, + ] + } +} +``` + +要驗證合同，您需要運行驗證命令，並輸入已部署合同的地址、網絡和參數（如有） 。 + +```bash +npx hardhat verify -network + +// example + +npx hardhat verify --network kairos 0x131b54E65c99d34BCA738F29051fDAceEa91C969 1000000000000000 +``` + +在您的終端中，您應該可以看到您的合同源代碼已成功提交驗證。 如果驗證成功，您應看到 "成功驗證合同"，並在 +[Kaiascope] (https://kairos.kaiascope.com/account/0x131b54E65c99d34BCA738F29051fDAceEa91C969?tabId=contractCode) 上有一個指向合同代碼的鏈接。 + +![](/img/build/smart-contracts/verify/terminal-hh-verify-ss.png) + +![](/img/build/smart-contracts/verify/scope-hh-verify-ss.png) + +## 實用鏈接 + +- [Hardhat驗證插件配置](https://docs.klaytnscope.com/contract/configuration-for-hardhat-verify-plugin) +- [在 Kaiascope 上使用 Hardhat 驗證合同](https://klaytn.foundation/verifying-contracts-using-hardhat-on-klaytnscope) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.mdx new file mode 100644 index 000000000000..7eb5ab059d8e --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/hardhat.mdx @@ -0,0 +1,151 @@ +--- +id: hardhat +title: Using Hardhat +--- + +import Tabs from '@theme/Tabs' +import TabItem from '@theme/TabItem' + +# How to Verify Smart Contracts Using Hardhat + +This guide allows you to automatically verify your smart contracts' source code on Kaiascope straight from your CLI using the Hardhat Verify Plugin. + +To verify your contract on Kaia, you need to add the following configuration to your `hardhat.config.js`: + +## Kaiascan + + + + ```js + module.exports = { + etherscan: { + apiKey: { + kaia: "unnecessary", + }, + customChains: [ + { + network: "kaia", + chainId: 8217, + urls: { + apiURL: "https://mainnet-api.kaiascan.io/hardhat-verify", + browserURL: "https://kaiascan.io", + } + }, + ] + } + } + ``` + + + + ```js + module.exports = { + etherscan: { + apiKey: { + kairos: "unnecessary", + }, + customChains: [ + { + network: "kairos", + chainId: 1001, + urls: { + apiURL: "https://kairos-api.kaiascan.io/hardhat-verify", + browserURL: "https://kairos.kaiascan.io", + } + }, + ] + } + } + ``` + + + +## Kaiascope + + + + ```js + module.exports = { + networks: { + kaia: { + chainId: 8217, + url: "RPC_URL", + }, + }, + etherscan: { + apiKey: { + kaia: "unnecessary", + }, + customChains: [ + { + network: "kaia", + chainId: 8217, + urls: { + apiURL: "https://api-cypress.klaytnscope.com/api", + browserURL: "https://kaiascope.com/", + }, + }, + ] + } + } + ``` + + + + ```js + module.exports = { + networks: { + kairos: { + chainId: 1001, + url: "RPC_URL", + }, + }, + etherscan: { + apiKey: { + kairos: "unnecessary", + }, + customChains: [ + { + network: "kairos", + chainId: 1001, + urls: { + apiURL: "https://api-baobab.klaytnscope.com/api", + browserURL: "https://kairos.kaiascope.com", + }, + }, + ] + } + } + ``` + + + +To verify the contract, you will run the verify command and pass in the address of the deployed contract, network and parameters if any. + +```bash +npx hardhat verify –network + +// example + +npx hardhat verify --network kairos 0x3e360fC99c4383e3adaAE9742c0fC983fDAa0535 +``` + +In your terminal you should see the source code for your contract was successfully submitted for verification. + +If the verification was successful, you should see Successfully verified contract and there will be a link to the contract code on [Kaiascan](https://kairos.kaiascan.io/address/0x3e360fC99c4383e3adaAE9742c0fC983fDAa0535?tabId=contract\&page=1) and [Kaiascope](https://baobab.klaytnscope.com/account/0x3e360fC99c4383e3adaAE9742c0fC983fDAa0535?tabId=contractCode) respectively. + +**Kaiascan** + +![](/img/build/smart-contracts/verify/kaiascan-terminal.png) +![](/img/build/smart-contracts/verify/kaiascan-verify.png) + +**Kaiascope** + +![](/img/build/smart-contracts/verify/kaiascope-terminal.png) +![](/img/build/smart-contracts/verify/kaiascope-verify.png) + +## Useful links + +* [Configuration for Hardhat Verify Plugin on Kaiascan](https://docs.kaiascan.io/hardhat-verify) +* [Configuration for Hardhat Verify Plugin on Kaiascope](https://docs.klaytnscope.com/contract/configuration-for-hardhat-verify-plugin) +* [Verifying contracts using Hardhat on Kaiascan](https://klaytn.foundation/verifying-contracts-using-hardhat-on-klaytnscope) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md new file mode 100644 index 000000000000..7efc7890b581 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/smart-contracts/verify/sourcify.md @@ -0,0 +1,51 @@ +--- +sidebar_label: 使用 Sourcify +--- + +# 如何使用 Sourcify 驗證智能合約 + +[Sourcify](sourcify.dev)是一個 Solidity（智能合約）源代碼驗證服務，適用於以太坊和與 EVM 兼容的鏈，如 Kaia。 它的一個獨特功能是利用[Solidity 元數據](https://docs.sourcify.dev/docs/metadata/) 文件來["完全驗證"](https://docs.sourcify.dev/docs/full-vs-partial-match/) 合同。 + +在本指南中，我們將瞭解如何使用 Sourcify 在 Foundry 上驗證智能合約。 + +## 快速開始 + +本指南希望您對使用 Foundry 開發智能合約有所瞭解。 請參閱 [Deploy smart contract using Foundry](../deploy/foundry.md) 開始使用。 Foundry 提供對 Sourcify 驗證的原生支持--你只需在鍛造命令中添加幾個標誌即可。 要使用 Foundry 與 Sourcify 驗證合同，請參閱以下步驟： + +## 部署和驗證合約： + +```bash +/* deploy */ + +forge create --rpc-url $KAIROS_RPC_URL --private-key $PRIVATE_KEY src/Counter.sol:Counter --broadcast +``` + +![](/img/build/smart-contracts/verify/sourcify-deploy.png) + +```bash +//* verify an already deployed contract as seen above *// + +forge verify-contract 0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2 src/Counter.sol:Counter --chain-id 1001 --verifier sourcify --verifier-url https://sourcify.dev/server/ +``` + +![](/img/build/smart-contracts/verify/sourcify-verify.png) + +您可以在 [此處](https://sourcify.dev/#/lookup/0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2) 查閱已驗證的合同 + +![](/img/build/smart-contracts/verify/sourcify-lookup-verify.png) + +## 檢查合約是否已驗證 + +```bash +forge verify-check 0x2a31C3f597d8FD0Fbc5Ff02439ce6c6aEFb680a2 --chain-id 1001 --verifier sourcify +``` + +![](/img/build/smart-contracts/verify/sourcify-verify.png) + +## 參考鏈接 + +- [源驗證器](https://sourcify.dev/#/verifier) +- [使用 Sourcify UI 驗證](https://docs.sourcify.dev/docs/how-to-verify/#using-the-ui-legacy) +- [使用 Sourcify 在 Hardhat 上進行驗證](https://docs.sourcify.dev/docs/how-to-verify/#hardhat) +- [使用 Sourcify 在 Remix 上進行驗證](https://docs.sourcify.dev/docs/how-to-verify/#remix-plugin) +- [Sourcify Playground](https://playground.sourcify.dev/) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md new file mode 100644 index 000000000000..d95081cf5307 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/block-explorers/block-explorers.md @@ -0,0 +1,9 @@ +# 積木探險家 + +該區塊鏈工具使用戶和愛好者能夠搜索有關區塊鏈的即時和歷史信息。 Kaia 上的區塊探索器包含有關 Kaia 的信息，因此用戶可以搜索 Kaia 上的區塊、交易、餘額、地址和合約。 + +由 Kaia 支持的探險家名單如下： + +- [Kaiascope](https://kaiascope.com/) +- [Kaiascan](https://www.kaiascan.io/) +- [OKX Kaia Explorer](https://www.okx.com/web3/explorer/kaia) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md new file mode 100644 index 000000000000..80252f413c7d --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/block-explorers/kaiascope.md @@ -0,0 +1,232 @@ +# Kaiascope + +Kaiascope 是 Kaia 網絡的區塊資源管理器。 Kaiascope 通過監控網絡健康狀況和提供 Kaia 網絡的各種統計數據，讓您深入瞭解 Kaia 網絡。 您還可以查看 Kaia 網絡上的區塊和交易數據以及智能合約列表。 + +- 有關 Kairos 網絡，請訪問 [https://kairos.kaiascope.com](https://kairos.kaiascope.com) +- 有關主網，請訪問 [https://kaiascope.com/](https://kaiascope.com/) + +![](/img/build/tools/scope_01_main.png) + +## 主要特點 + +請注意，部分功能正在開發中。 + +- 網絡概覽 +- 區塊搜索 +- 交易搜索 +- 賬戶搜索 +- 事件日誌搜索 +- 整塊提案人信息 + +在隨後的章節中，我們將參觀 Kaiascope 的主要功能和屏幕截圖。 功能分為四類：儀表盤、列表視圖、詳細視圖和搜索。 + +## 儀錶板 + +網絡信息顯示在儀錶板中。 這些信息包括平均區塊生成時間、區塊中的平均交易數量、共識節點數量以及交易的最新趨勢。 + +![](/img/build/tools/scope_02_main_indicator.png) + +- 區塊高度：最新的區塊高度。 它顯示了自創世以來已經生成了多少區塊。 +- 網絡性能：它通過四項指標顯示 Kaia 的網絡性能。 + - 共識節點：上圖顯示有 15 個節點參與了共識過程。 + - 平均塊生成時間（1 小時）：顯示過去一小時內生成數據塊的平均時間。 + - 平均塊生成時間（24 小時）：它顯示了過去 24 小時內生成數據塊的平均時間。 + - Avg TX Per Block （24 小時）：過去 24 小時內包含在一個數據塊中的平均交易次數。 +- 交易歷史（14 天）：圖表顯示過去 14 天內的每日交易次數。 您可以看到過去兩週交易量的變化趨勢。 + +### 最近的區塊和交易 + +這些列表分別顯示最近創建的區塊和事務。 點擊窗格右上角的刷新按鈕，即可獲得最新信息。 在列表底部，單擊 "查看全部 "按鈕將進入[列表視圖](#list-view)。 + +![](/img/build/tools/scope_03_main_list.png) + +### 網絡狀態和網絡選擇器 + +![](/img/build/tools/network_status.gif) + +網站右上角有網絡狀態指示燈和網絡選擇器下拉菜單。 + +- 網絡狀態指示燈 + - 網絡正常：Kaiascope 正常運行。 網絡狀態正常。 + - 數據延遲：Kaiascope 正在進行系統維護。 數據處於延遲狀態。 + - 數據準確性：Kaiascope 正在同步數據，請稍候。 +- 網絡選擇器下拉菜單 + - 您可以從菜單中選擇 Kaia 主網和 Kairos 測試網。 + +## 列表查看 + +如果您想進一步瞭解 Kaia 網絡的狀態，可以查看最近生成的區塊和交易列表。 要訪問列表頁面，請單擊屏幕左側導航欄上的按鈕。 + +### 塊 + +![](/img/build/tools/scope_04_block_list.png) + +最近生成的區塊列表。 要更新信息，請點擊刷新。 + +- 區塊：區塊的唯一編號。 從零開始（創世區塊），每次生成一個區塊時都會依次給出。 +- 時間：區塊生成後的持續時間。 您可以通過鼠標懸停來查看確切的日期和時間。 +- TX 總數：區塊中包含的交易總數。 +- 區塊提議者：隨機但確定地選擇提出區塊的共識節點。 點擊地址，即可輕鬆進入詳情頁面。 +- 獎勵：新鑄幣的 KAIA （9.6 KAIA/）和區塊中使用的交易費的總和。 列表僅顯示 Kaia 治理委員會獎勵、貢獻證明和 Kaia 生態系統基金的總和。 將鼠標懸停在區塊詳情頁面上的區塊獎勵部分，即可查看詳細信息。 有關區塊獎勵分配系統的更多詳情，請參閱\[Kaia 代幣經濟]。 +- 大小：數據塊的大小，以字節為單位。 包含的交易越多，區塊大小就越大。 + +### 交易 + +![](/img/build/tools/scope_05_tx_list.png) + +最近執行的事務列表。 要更新信息，請點擊刷新。 + +- TX 哈希值：交易的唯一標識符。 如需瞭解更多信息，請點擊散列進入詳細頁面。 如果交易失敗，旁邊會出現一個紅色感嘆號。 +- Block \#: 包含此交易的區塊編號。 點擊號碼後，您將進入該區塊的詳細信息頁面。 +- 時間：交易執行後的持續時間。 您可以通過鼠標懸停來查看確切的日期和時間。 +- 發件人 -> 收件人：發件人和收件人的地址。 點擊地址，即可輕鬆進入詳情頁面。 如果文件圖標顯示在地址旁邊，則表示該地址是一份合同。 +- TX 類型：交易類型。 您可以使用過濾器來獲取特定類型的交易。 更多信息，請訪問 \[交易]。 +- 金額：通過交易轉移的價值量。 +- TX 費用：處理交易的實際費用。 + +## 詳細查看 + +有關單個區塊、交易、賬戶和合約的詳細信息，請參見本頁。 要轉到詳細信息視圖，可以從搜索欄中搜索實體，或從列表視圖中單擊項目。 + +### 街區 + +![](/img/build/tools/scope_08_block_detail.png) + +#### 概述 + +區塊的總體信息。 + +- 時間： 生成區塊後的時間。 旁邊還會顯示確切的日期時間。 +- 哈希值：區塊的唯一標識符。 按下複製按鈕，就可以輕鬆複製哈希值。 +- 父哈希值：前一個區塊的唯一標識符。 點擊散列可進入父散列的詳細視圖。 +- TX 總數：區塊中包含的交易總數。 +- 區塊獎勵：新鑄幣的 KAIA （9.6 KAIA/）和區塊中收取的交易費的總和。 將鼠標懸停，您將看到有關 Kaia 治理委員會獎勵、貢獻證明和 Kaia 生態系統基金的詳細信息。 有關區塊獎勵分配系統的更多詳情，請參閱\[Kaia 代幣經濟]。 +- 數據塊大小：數據塊的大小（以字節為單位）。 包含的交易越多，區塊大小就越大。 + +#### 委員會 + +提出並驗證區塊的共識節點列表。 + +- 區塊提議者：隨機但確定地選擇提出區塊的共識節點。 點擊地址，就可以輕鬆進入節點的詳細視圖。 +- 驗證者：驗證區塊的共識節點。 點擊地址，就可以輕鬆進入節點的詳細視圖。 + +#### 交易 + +區塊中包含的交易列表。 + +### 交易 + +![](/img/build/tools/scope_09_tx_detail.png) + +#### 概述 + +交易的總體信息。 + +- 狀態指示器：在右上角。 交易是否成功的指標。 +- TX 類型：交易類型。 更多信息，請參閱 \[交易]。 +- Block \#：包含此交易的區塊編號。 點擊數字可進入區塊的詳細視圖。 +- 發件人 -> 收件人：發件人和收件人的地址。 點擊地址，即可進入賬戶的詳細視圖。 如果地址旁邊顯示文件圖標，則表示該地址已簽約。 +- 費用支付人：當 TX 類型為 "收費委託 "或 "按比例收費委託 "時顯示。 點擊繳費人地址後，即可進入賬戶的詳細視圖。 +- Time（時間）：交易執行後的時間。 +- Nonce：發件人地址發送的交易編號。 從零開始，每次發送交易時，它都會依次增加。 +- 金額：本次交易中轉移的價值金額。 +- Gas 價格：單位為 KAIA 的天然氣成本。 在 Kaia 網絡中，Gas 價格是固定的。 +- 使用的氣體：執行交易時使用的確切氣體。 +- 汽油限額：發件人願意為此次交易支付的最大汽油量。 +- TX 費用：處理交易的實際費用。 計算方法：Gas 價格乘以天然氣用量。 +- 發件人 TX 費用：當 TX 類型為帶比率的收費委託時顯示。 發件人支付的 TX 費用部分。 +- TX 費用（按費用支付方）：TX 類型為按比例收費委託時顯示。 TX 費用中由付費者支付的部分。 + +#### 輸入數據 + +發件人或合同提供的額外數據。 + +### 賬戶 + +![](/img/build/tools/scope_10_account_detail.png) + +#### 概述 + +賬戶的總體信息。 + +- 地址（Hex\ ）：賬戶的唯一地址。 +- 餘額：該賬戶擁有的 KAIA 總額。 +- TX 總數：該賬戶發送或接收的交易總數。 + +#### 交易 + +與該賬戶相關的交易列表。 箭頭的顏色表示賬戶是發送方還是接收方。 + +### 合同 + +![](/img/build/tools/scope_11_contract_detail.png) + +#### 概述 + +合同的總體信息。 + +- Account\(Hex\)：合同的唯一地址。 +- 餘額：該合同的 KAIA 總金額。 +- 合同創建者：部署此合同的賬戶。 點擊地址，即可進入賬戶的詳細視圖。 +- TX 總數：該合同收到的交易總數。 +- 合同創建 TX：部署此合同的交易。 點擊哈希值可進入交易的詳細視圖。 + +#### 交易 + +與本合同有關的交易清單。 + +## 搜索 + +通過 Kaiascope，您可以搜索有關賬戶、合約、交易和區塊的信息。 搜索欄位於每個頁面上，方便用戶訪問。 輸入一個有效的關鍵字，就可以進入實體的詳細視圖。 + +![](/img/build/tools/scope_06_search.png) + +### 搜索關鍵詞 + +在主網版本中，可搜索的關鍵字如下： + +- 區塊 +- 德克薩斯州哈希 +- Address （賬戶，合同） + +### 關鍵詞格式 + +每個關鍵詞的獨特特徵如下： + +#### 街區 + +- 僅限十進制數 \[0~9\] + +#### 德克薩斯州哈希 + +- 66 個字符長 +- 以前綴 `0x` 開頭 +- 僅限十六進制數 （[0~9, a~f\] + +#### 地址 + +- 42 個字符長 +- 以前綴 `0x` 開始 +- 僅限十六進制數 （[0~9, a~f\] + +### 搜索錯誤 + +![](/img/build/tools/scope_07_noresult.png) + +如果搜索的關鍵字不符合指定格式或信息尚未生成，則不會出現任何數據。 + +#### 錯誤格式 （TX Hash / Address\) + +- 字符數錯誤 +- 不以前綴 `0x` 開頭 +- 包含特殊字符或非十六進制字符 + +#### 不存在 + +- 尚未生成的區塊（如果輸入的區塊編號高於最近生成的區塊編號） +- 不存在 TX 哈希值 + +[Transactions]: ../../../learn/transactions/transactions.md +[Kaia Token Economy]: ../../../learn/token-economy.md + +//scope_04_block_list diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md new file mode 100644 index 000000000000..8e2d56a1f1fa --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/cross-chain.md @@ -0,0 +1,24 @@ +# 跨鏈互操作性 + +跨鏈互操作性協議旨在將原本孤立和獨立的區塊鏈網絡連接起來。 這些協議使不同的鏈能夠互動，讓流動性和狀態在它們之間流動。 通過建立在不同區塊鏈網絡之間傳輸資產和數據的規則和流程，跨鏈互操作性協議促進了原本獨立的系統之間的無縫協作和信息交換。 + +## 範圍廣泛的跨鏈解決方案 + +跨鏈互操作性是一個包含各種技術的綜合概念： + +1. **跨鏈消息協議**：這些協議可實現廣泛的互操作性，支持數據交換和跨鏈智能合約執行等多種操作。 + +2. **跨鏈橋樑**：跨鏈橋是跨鏈解決方案的一個特定子集，主要側重於鏈之間的資產轉移。 它們在連接不同區塊鏈生態系統中的資產方面發揮著至關重要的作用，但與一般的消息傳遞協議相比，它們的功能更為專業。 + +## 凱亞的兼容性 + +Kaia 網絡目前與領先的跨鏈解決方案兼容，增強了其在更廣泛的區塊鏈環境中的連接性。 Kaia 目前支持以下功能： + +### 跨鏈消息傳遞協議 + +- [LayerZero](https://layerzero.network/) +- [蟲洞](https://wormhole.com/) + +### 跨鏈橋樑 + +- [星際之門](https://stargate.finance/) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md new file mode 100644 index 000000000000..0d3ec62f78a3 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/layerzero.md @@ -0,0 +1,13 @@ +# Layerzero + +## 導言 + +[LayerZero](https://docs.layerzero.network/v2)作為Web3中的全鏈互操作性協議，使應用程序能夠跨區塊鏈移動數據，通過不可變的智能合約獨特地支持抗審查信息和無許可開發。 Layerzero 為開發全能鏈應用程序提供了一套豐富的工具，因此開發人員可以輕鬆地[發送任意數據](https://docs.layerzero.network/v2/home/protocol/contract-standards#oapp)、[外部函數調用](https://docs.layerzero.network/v2/developers/evm/oapp/message-design-patterns)和[令牌](https://docs.layerzero.network/v2/home/protocol/contract-standards#oft)，同時保持對其應用程序的完全自主和控制。 + +## 使用方法 + +Layerzero 同時支持 [Kaia Mainnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#klaytn) 和 [Kairos Testnet](https://docs.layerzero.network/v2/developers/evm/technical-reference/deployed-contracts#klaytn-baobab) 。 要開始在 Kaia 上使用 LayerZero，請參閱以下指南： + +- [LayerZero V2 OApp 快速入門](https://docs.layerzero.network/v2/developers/evm/oapp/overview) +- [LayerZero V2 OFT 快速入門](https://docs.layerzero.network/v2/developers/evm/oft/quickstart) +- [LayerZero V2 ONFT 快速入門](https://docs.layerzero.network/v2/developers/evm/onft/quickstart) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md new file mode 100644 index 000000000000..7aeb9d61d417 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/stargate.md @@ -0,0 +1,11 @@ +# Stargate + +## 導言 + +[Stargate](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs) 是首個完全可組合的原生資產橋接器，也是首個基於 LayerZero 構建的 dApp。 Stargate的核心是使跨鏈流動性轉移成為無縫的單一交易流程。 有了Stargate，用戶可以在一次交易中跨鏈交換原生資產。 這意味著您可以在一次交易中將 ETH 換成 KAIA。 + +## 使用方法 + +Stargate為開發人員提供了一種在應用程序中以編程方式執行交換的方法。 您可以在 [Kaia Mainnet](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/technical-reference/mainnet-contracts#klaytn) 和 [Kairos Testnet](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/technical-reference/testnet-contracts#klaytn-baobab-testnet) 上以編程方式執行交換。 要開始使用，請參閱以下指南： + +- [如何交換](https://stargateprotocol.gitbook.io/stargate/v2-developer-docs/integrate-with-stargate/how-to-swap) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md new file mode 100644 index 000000000000..208e0e583ea0 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/cross-chain/wormhole.md @@ -0,0 +1,13 @@ +# Wormhole + +## 導言 + +[Wormhole](https://wormhole.com/docs/)是一個支持多鏈應用程序和橋樑的互操作性平臺。 它目前支持包括 Kaia 在內的 30 多條鏈。 通過集成蟲洞，Kaia 應用程序可以使任何代幣成為原生多鏈，按需提取任何鏈上數據，並構建自定義多鏈協議。 + +## 使用方法 + +Wormhole 同時支持 [Kaia Mainnet](https://wormhole.com/docs/build/start-building/supported-networks/evm/#__tabbed_34_1) 和 [Kairos Testnet](https://wormhole.com/docs/build/start-building/supported-networks/evm/#__tabbed_35_1) 。 要開始在 Kaia 上使用 Wormhole，請參閱以下指南： + +- [創建跨鏈信息傳遞合約](https://wormhole.com/docs/tutorials/messaging/cross-chain-contracts/) +- [創建跨鏈令牌傳輸](https://wormhole.com/docs/tutorials/messaging/cross-chain-token-contracts/) +- [Github 示例](https://github.com/wormhole-foundation/wormhole-examples) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md new file mode 100644 index 000000000000..fbc0d460e357 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/indexers.md @@ -0,0 +1,8 @@ +# Indexers + +區塊鏈索引器是區塊鏈技術中使用的工具，用於提高搜索、查詢和訪問存儲在區塊鏈上的數據的效率和速度。 它們創建並維護區塊鏈數據的有序數據庫，使用戶能夠快速檢索信息，而無需從頭開始處理整個區塊鏈。 + +以下供應商已與 Kaia 集成，提供區塊鏈索引服務： + +- [圖表](https://thegraph.com/) +- [SubQuery Network](https://academy.subquery.network/) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md new file mode 100644 index 000000000000..457991d652a7 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/subquery.md @@ -0,0 +1,38 @@ +--- +sidebar_label: SubQuery +--- + +# SubQuery多鏈索引器 + +SubQuery 是領先的區塊鏈數據索引器，為開發人員的 Web3 項目提供快速、靈活、通用、開源和去中心化的 API。 SubQuery SDK 允許開發人員獲取豐富的索引數據，並以更快、更高效的方式構建直觀、身臨其境的去中心化應用程序。 SubQuery 支持 100 多個生態系統，包括 Kaia 的 EVM、Cosmos、以太坊、Polygon、Polkadot、Algorand、NEAR 和 Avalanche。 + +SubQuery 的另一個競爭優勢是，它不僅能在一個鏈上彙總數據，還能在一個項目中彙總多個區塊鏈上的數據。 這樣就可以創建功能豐富的儀表盤分析或多鏈塊掃描儀。 + +其他優勢還包括多個 RPC 端點配置的卓越性能、多工作站功能和可配置的緩存架構。 要了解更多信息，請訪問我們的 [文檔](https://academy.subquery.network/)。 + +## 開始 + +看看這個[SubQuery 入門項目](https://github.com/subquery/ethereum-subql-starter/tree/main/Kaia/klaytn-starter)，它通過索引來自 Kaia Network 上 Orbit ETH 的所有轉賬和批准事件，介紹了 SubQuery 對 Kaia 的支持。 + +你也可以跟著這個 [step by step guide](https://academy.subquery.network/quickstart/quickstart.html) 來熟悉 SubQuery，或者查看 [Kaia x SubQuery workshop](https://www.youtube.com/watch?v=40R5O1kL3v4) 來觀看實際演示。 + +## 運行和託管 Kaia 子查詢 API + +SubQuery 是開源的，這意味著你可以通過以下三種方式自由運行它： + +- 在您自己的電腦上或您選擇的雲服務提供商上運行。 查看如何在本地運行 SubQuery 的說明 [此處](https://academy.subquery.network/run_publish/run.html)。 + +您可以將其發佈到 SubQuery 的企業級 [託管服務](https://managedservice.subquery.network/login)，我們將在生產準備就緒的服務中託管您的 SubQuery 項目，為關鍵任務數據提供零停機時間的藍色/綠色部署。 甚至還有慷慨的免費層級。 [瞭解方法](https://academy.subquery.network/run_publish/publish.html)。 + +您可以將其發佈到去中心化的 SubQuery 網絡，這是面向 dApp 開發人員的最開放、性能最好、最可靠和可擴展的數據服務。 SubQuery 網絡以激勵和可驗證的方式為全球社區提供數據索引和服務，並從 Kaia 推出之初就為其提供支持。 + +## 資源 + +下面是一些幫助您開始使用 SubQuery 的其他資源： + +- [子查詢網站](https://subquery.network/?utm_source=klaytn\&utm_medium=partner-docs) +- [文件](https://academy.subquery.network/?utm_source=klaytn\&utm_medium=partner-docs) +- [SubQuery Kaia 支持公告](https://subquery.medium.com/subquerys-data-indexing-supports-builders-on-klaytn-e5a3aec4bc14?utm_source=klaytn\&utm_medium=partner-docs) +- [Kaia快速啟動](https://academy.subquery.network/quickstart/quickstart_chains/klaytn.html/?utm_source=klaytn\&utm_medium=partner-docs) +- [Kaia啟動項目](https://github.com/subquery/ethereum-subql-starter/tree/main/Kaia/klaytn-starter) +- [Discord支持](https://discord.com/invite/subquery/?utm_source=klaytn\&utm_medium=partner-docs) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md new file mode 100644 index 000000000000..4befff378938 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/indexers/thegraph.md @@ -0,0 +1,205 @@ +--- +sidebar_label: The Graph +--- + +# The Graph + +在構建 dapp 時，獲取智能合約的歷史數據可能會令人沮喪。 [The Graph](https://thegraph.com/) 通過被稱為子圖的應用程序接口，提供了一種查詢智能合約數據的簡便方法。 圖形的基礎設施依賴於索引器的去中心化網絡，使您的 dapp 真正實現去中心化。 + +Kaia Mainnet 和 Testnet 均由 The Graph 提供支持。 + +## 快速入門 + +設置這些子圖只需幾分鐘。 要開始操作，請遵循以下三個步驟： + +1. 初始化子圖項目 +2. 部署和發佈 +3. 從您的應用程序中查詢 + +定價 + +- Studio 中的速率限制測試終點是免費的。 +- 去中心化網絡的 API 調用按次付費，每 10 萬次查詢收費 4 美元。 前 100K 次查詢免費！ + +下面是一個步驟： + +## 1. 初始化子圖項目 + +### 在 Subgraph Studio 上創建子圖 + +訪問 [Subgraph Studio] (https://thegraph.com/studio/) 並連接您的錢包。 連接錢包後，您可以點擊 "創建子圖"。 選擇名稱時，建議使用標題大小寫："子圖名稱鏈名稱"。 + +![Create a Subgraph](/img/build/tools/graph/01-create-subgraph.png) + +然後，您將進入您的子圖頁面。 您需要的所有 CLI 命令都將顯示在頁面右側： + +![CLI commands](/img/build/tools/graph/02-cli-commands.webp) + +### 安裝圖形 CLI + +在本地計算機上運行以下程序： + +``` +npm install -g @graphprotocol/graph-cli +``` + +### 初始化子圖 + +您可以直接從您的子圖頁面中複製，以包含您的特定子圖標題： + +``` +graph init --studio +``` + +系統會提示您提供子圖的一些信息，如下所示： + +![CLI sample](/img/build/tools/graph/03-cli-sample.webp) + +輸入合約信息後，graph-cli 會嘗試從 blockexplorer API 獲取 ABI、StartBLock 和合約名稱。 + +不過，KaiaScan 的 API 還沒有準備好，所以當被要求重試時，只需說 "不"。 以下是手動獲取這些信息的方法： + +1. ABI：您需要在運行 `graph init` 的同一目錄下準備一個包含 ABI 的 json 文件。 從[Kaiascan 上的合同頁面](https://kaiascan.io/address/0x5096db80b21ef45230c9e423c373f1fc9c0198dd)，進入 "合同 "選項卡，點擊 "查看代碼"，就能複製 ABI。 將其保存為 json 文件，放在運行 `graph init` 的同一文件夾中。 在上面的截圖中，它被保存為 `abi.json`。 + ![Finding ABI](/img/build/tools/graph/04-kaiascan-abi.webp) + +2. 啟動區塊：點擊創建合約的交易哈希值。 在那裡你會找到創建合同的區塊。 + ![contract creation](/img/build/tools/graph/05-contract-creation.webp) + +3. 合同名稱：輸入合同名稱即可。 如果這是您在該子圖中索引的唯一一份合同，那麼使用默認的 `Contract` 即可。 + +## 2) 部署和發佈 + +### 部署到 Subgraph Studio + +首先運行這些命令： + +```bash +$ graph codegen +$ graph build +``` + +然後運行這些程序來驗證和部署您的子圖。 您可以直接從 Studio 中的子圖頁面複製這些命令，以包含特定的部署密鑰和子圖標題： + +```bash +$ graph auth --studio +$ graph deploy --studio +``` + +系統會要求您提供版本標籤。 您可以輸入類似 v0.0.1 的內容，但也可以自由選擇格式。 + +### 測試子圖 + +您可以在操場部分進行示例查詢，測試您的子圖。 詳細信息 "選項卡將顯示 API 端點。 您可以使用該端點從您的 dapp 進行測試。 + +![Playground](/img/build/tools/graph/06-playground.png) + +### 將子圖發佈到圖譜的去中心化網絡中 + +一旦您的子圖可以投入生產，您就可以將其發佈到去中心化網絡中。 在 Subgraph Studio 的子圖頁面上，點擊 "發佈 "按鈕： + +![publish button](/img/build/tools/graph/07-studio-publish-subgraph.webp) + +> **注：** +> +> - Kaia 暫時顯示為 "部分支持"，因為為索引員解鎖獎勵的最終鏈上投票流程尚未完成。 目前，Edge & Node 的索引器（升級索引器）是唯一支持所有 Kaia 子圖的索引器。 +> - 儘管您的子圖正在索引來自 Kaia、以太坊或任何其他[支持鏈](https://thegraph.com/docs/en/developing/supported-networks/)的數據，但該圖的智能合約都在 Arbitrum One 上。 + +## 3. 查詢子圖 + +祝賀你 現在，您可以在分散式網絡上查詢您的子圖！ + +對於去中心化網絡上的任何子圖，只要將 GraphQL 查詢傳遞到子圖的查詢 URL（可在資源管理器頁面頂部找到），就可以開始對其進行查詢。 + +下面是 Messari 在 [CryptoPunks Ethereum 子圖](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) 中的一個例子： + +![Query URL](/img/build/tools/graph/08-query-url.png) + +該子圖的查詢 URL 為 + +`https://gateway-arbitrum.network.thegraph.com/api/`**[api-key]**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK` + +現在，您只需填寫自己的 API 密鑰，即可開始向該端點發送 GraphQL 查詢。 + +### 獲取自己的應用程序接口密鑰 + +![API keys](/img/build/tools/graph/09-apikeys.png) + +在 Subgraph Studio 中，您會看到頁面頂部的 "API 密鑰 "菜單。 您可以在此創建 API 密鑰。 + +## 附錄 + +### 查詢示例 + +該查詢顯示了售價最昂貴的 CryptoPunks。 + +```graphql +{ + trades(orderBy: priceETH, orderDirection: desc) { + priceETH + tokenId + } +} + +``` + +將其輸入查詢 URL 會返回此結果： + +``` +{ + "數據"：{ + "trades"：[ + { + "priceETH"："124457.067524886018255505", + "tokenId"："9998" + }, + { + "priceETH"："8000", + "tokenId"："5822" + }, +// ... +``` + + + +### 代碼示例 + +```jsx +const axios = require('axios'); + +const graphqlQuery = `{ + trades(orderBy: priceETH, orderDirection: desc) { + priceETH + tokenId + } +}`; +const queryUrl = 'https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK' + +const graphQLRequest = { + method: 'post', + url: queryUrl, + data: { + query: graphqlQuery, + }, +}; + +// Send the GraphQL query +axios(graphQLRequest) + .then((response) => { + // Handle the response here + const data = response.data.data + console.log(data) + + }) + .catch((error) => { + // Handle any errors + console.error(error); + }); +``` + +### 其他資源： + +- 要探索優化和定製子圖以提高性能的所有方法，請閱讀 [在此創建子圖](https://thegraph.com/docs/en/developing/creating-a-subgraph/) 的更多信息。 +- 有關從子圖中查詢數據的更多信息，請閱讀 [此處](https://thegraph.com/docs/en/querying/querying-the-graph/)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md new file mode 100644 index 000000000000..9752b799724d --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/kaia-contracts-wizard.md @@ -0,0 +1,461 @@ +# Kaia Contracts Wizard + +![](/img/banners/kaia-kcw.png) + +## 導言 + +Kaia 優先考慮提供無縫的開發人員體驗，這也是創建 Kaia 合同嚮導（KCW）的驅動力。 KCW 是一種交互式工具，可讓您毫不費力地啟動智能合約，並利用 [Kaia Contracts](https://github.com/kaiachain/kaia-contracts) 中經過測試的安全組件。 從本質上講，它通過利用 Kaia 合約的組件簡化了智能合約的開發過程。 值得注意的是，Kaia 合約嚮導建立在 OpenZeppelin 嚮導的基礎之上，進一步加強了智能合約開發的安全性。 + +在本指南中，您將 + +- 瞭解 Kaia 合同嚮導的基本功能。 +- 使用 Kaia Contracts Wizard 生成和定製智能合約代碼。 +- 使用 Foundry 腳本系統將 Kaia 合同部署到 Kaia 網絡 (Kairos)。 + +## 探索 Kaia 合同嚮導 + +Kaia Contracts Wizard 將自己定位為使用 Kaia Contracts 編寫智能合約的最快、最簡單的方法。 在本節中，我們將深入瞭解 Kaia 合同嚮導的各個組件和部分。 + +目前，Kaia 合約嚮導支持以下令牌標準： + +- [KIP-7](https://kips.kaia.io/KIPs/kip-7) - 這是 Kaia 的可替代令牌標準。 可互換是指所有代幣都可分割和互換，即具有相同的價值。 可替代代幣的一個典型例子就是法定貨幣，每張等面值的鈔票都具有相同的價值。 +- [KIP-17](https://kips.kaia.io/KIPs/kip-17) - 這是 Kaia 的不可篡改令牌標準。 不可竄改是指每個標記都是不可分割的，因此也是獨一無二的。 KIP17 代幣可以代表一個獨特物品的所有權，無論是實物財產還是虛擬收藏品，如圖片、遊戲中的物品、不動產等。 +- [KIP-37](https://kips.kaia.io/KIPs/kip-37) - 這被稱為 Kaia 的多令牌標準，因為它可以在單個智能合約中同時表示可替換令牌和不可替換令牌。 + +與我們的 [Ethereum Equivalence](https://medium.com/klaytn/toward-ethereum-equivalence-1-introducing-klaytn-v1-8-0-971911be7ff9) 支持一致，Kaia 合約嚮導也支持 [ERC20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/)、[ERC721](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/)、[ERC1155](https://ethereum.org/en/developers/docs/standards/tokens/erc-1155/)。 + +Kaia 合同嚮導由以下部分組成： + +- **令牌標準部分**：該選項卡包含 Kaia 合約嚮導支持的所有不同令牌標準。 + +- **設置部分**：該部分提供每個代幣標準的初步設置，如代幣名稱、符號、預鑄幣（合約部署時的代幣供應）和 URI（針對不可兌換代幣）。 + +- **功能部分**：包括每個令牌標準的所有功能。 您可以在以下鏈接中找到更多關於每種令牌可用的不同擴展名的信息： + + - [KIP7](https://github.com/kaiachain/kaia-contracts/tree/master/contracts/KIP/token/KIP7/extensions) + - [KIP17](https://github.com/kaiachain/kaia-contracts/tree/master/contracts/KIP/token/KIP17/extensions) + - [KIP37](https://github.com/kaiachain/kaia-contracts/tree/master/contracts/KIP/token/KIP37/extensions) + +- **訪問控制部分**：包括每個令牌標準的所有可用訪問控制機制。 + +- **交互式代碼顯示部分**：顯示根據用戶設置的配置生成的智能合約代碼。 + +![](/img/build/tools/kcw-image.png) + +在瞭解了 Kaia 合約嚮導的各個部分後，您現在可以選擇想要的合約類型（目前支持 **KIP7**、**KIP17**、**KIP37**、**ERC20**、**ERC721**、**ERC1155**、**Governor** 和自定義合約），設置參數和所需功能（令牌名稱、符號、預鑄幣量、訪問控制等），然後合約嚮導將生成所有必要的代碼。 因此，生成的代碼可以隨時進行編譯和部署，也可以作為起點，通過特定的應用邏輯進行進一步定製。 + +## 在 Kaia 網絡上定製和部署 Kaia 合約 + +在本節中，您將使用 Foundry 將 kaia 合約嚮導生成的代碼部署到 Kaia Testnet Kairos。 生成的代碼將作為起點，並進一步定製，以適應 KIP7 和 KIP17 代幣的空投合約。 而在另一端，生成的 KIP37 代碼將按原樣使用。 + +讓我們開始吧！ + +### 先決條件 + +要跟上本教程，先決條件如下： + +- 確保安裝了 [foundry](https://book.getfoundry.sh/getting-started/installation)。 +- 克隆 [klaytn-foundry-starterkit](https://github.com/ayo-klaytn/klaytn-foundry-starterkit) 代碼。 +- [MetaMask](../tutorials/connecting-metamask.mdx#install-metamask)：用於部署合約、簽署事務和與合約交互。 +- RPC 端點：您可以從支持的[端點提供程序](../../references/public-en.md)中獲取。 +- 從 [水龍頭](https://faucet.kaia.io)測試 KAIA：為賬戶注入足夠的 KAIA。 + +### 開始 + +本指南將指導您簡單實現 KIP7 和 KIP17 令牌標準的空投合約。 在空投合約中，項目的創建者會直接向特定的錢包鑄造各自的代幣。 在接下來的章節中，我們將分別介紹如何定製和部署每種令牌空投合約。 + +### 定製令牌合約 + +**將 KIP7 合同定製為 KIP7 空投合同。** + +在將 KIP7 合同修改為空投合同之前，您需要對其進行定製。 為此，請按照以下步驟操作： + +1. 導航至 [wizard.klaytn.foundation](https://wizard.klaytn.foundation/)。 +2. 在**合同**選項卡上選擇**KIP7** +3. 下一步是在**設置**選項卡中填寫名稱（KIP7 代幣空投）和符號（KTA）。 鑄幣前區域為空 +4. 隨後，在**功能**選項卡上，勾選**可薄荷**功能框，它就會自動選擇**訪問控制**選項卡上的可擁有功能。 + +進行這些配置後，Kaia 合同嚮導就會變成這樣： + +![](/img/build/tools/kip7-kcw.png) + +以下是生成的代碼： + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.4; +import "@kaiachain/contracts/KIP/token/KIP7/KIP7.sol"; +import "@kaiachain/contracts/access/Ownable.sol"; +contract KIP7TokenAirdrop is KIP7, Ownable { + constructor() KIP7("KIP7 Token Airdrop", "KTA") {} + function supportsInterface(bytes4 interfaceId) + public + view + virtual + override + returns (bool) + { + return + super.supportsInterface(interfaceId); + } + function mint(address to, uint256 amount) public onlyOwner { + _mint(to, amount); + } +} +``` + +接下來要做的就是修改上面的代碼，以適應我們的空投執行，看起來就像這樣： + +```solidity +//SPDX-License-Identifier: MIT +pragma solidity ^0.8.4; +import "@kaiachain/contracts/KIP/token/KIP7/KIP7.sol"; +import "@kaiachain/contracts/access/Ownable.sol"; +contract KIP7TokenAirdrop is KIP7, Ownable { + constructor() KIP7("KIP7 Token Airdrop", "KTA") { + } + // airdrop fungible token + function airdropTokens(address[] calldata wAddresses, uint[] calldata tAmount) public onlyOwner { + require(wAddresses.length == tAmount.length, "Must be same lenght"); + for (uint256 i = 0; i < wAddresses.length; i++) { + _mintSingleTokens(wAddresses[i], tAmount[i]); + } + } + function _mintSingleTokens(address wAddress, uint amount) private { + _mint(wAddress, amount); + } + function supportsInterface(bytes4 interfaceId) + public + view + virtual + override + returns (bool) + { + return + super.supportsInterface(interfaceId); + } +} +``` + +從上面修改的代碼中可以看到，我們添加了一個名為 `airdropTokens()` 的新函數。 該函數向某些選定的地址鑄造代幣，且只能由合約的創建者--"onlyOwner"--調用。 + +隨後，我們將_公共_ **mint()** _onlyOwner_函數修改為**_mintSingleTokens()** 私有。 + +現在我們已經準備好 KIP7 空投合同代碼，下一步是在項目目錄的 src 文件夾中新建一個名為 airdropKIP7.sol 的文件，並將修改後的代碼粘貼到該文件中。 + +**將 KIP17 合同定製為 KIP17 空投合同。** + +在將 KIP17 合同修改為空投合同之前，您需要對其進行定製。 為此，請按照以下步驟操作： + +1. 導航至 [wizard.klaytn.foundation](https://wizard.klaytn.foundation/)。 +2. 在**合同**選項卡上選擇**KIP17** +3. 下一步是在**設置**選項卡中填寫名稱（KIP7 NFT Airdrop）和符號（KNA）。 基礎 URI 字段應為空。 +4. 隨後，在**特性**選項卡上，勾選**可編輯**、**自動遞增索引**和**可數**特性框。 您會發現**訪問控制**選項卡中的 "可擁有 "功能已被自動選中。 + +進行這些配置後，Kaia 合同嚮導就會變成這樣： + +![](/img/build/tools/kip17-kcw.png) + +以下是生成的代碼： + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.4; +import "@kaiachain/contracts/KIP/token/KIP17/KIP17.sol"; +import "@kaiachain/contracts/KIP/token/KIP17/extensions/KIP17Enumerable.sol"; +import "@kaiachain/contracts/access/Ownable.sol"; +import "@kaiachain/contracts/utils/Counters.sol"; +contract KIP17NFTAirdrop is KIP17, KIP17Enumerable, Ownable { + using Counters for Counters.Counter; + Counters.Counter private _tokenIdCounter; + constructor() KIP17("KIP17 NFT Airdrop", "KNA") {} + function safeMint(address to) public onlyOwner { + uint256 tokenId = _tokenIdCounter.current(); + _tokenIdCounter.increment(); + _safeMint(to, tokenId); + } + // The following functions are overrides required by Solidity. + function _beforeTokenTransfer(address from, address to, uint256 tokenId) + internal + override(KIP17, KIP17Enumerable) + { + super._beforeTokenTransfer(from, to, tokenId); + } + function supportsInterface(bytes4 interfaceId) + public + view + override(KIP17, KIP17Enumerable) + returns (bool) + { + return super.supportsInterface(interfaceId); + } +} +``` + +接下來要做的就是修改上面的代碼，以適應我們的空投執行，看起來就像這樣： + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.4; +import "@kaiachain/contracts/KIP/token/KIP17/KIP17.sol"; +import "@kaiachain/contracts/KIP/token/KIP17/extensions/KIP17Enumerable.sol"; +import "@kaiachain/contracts/access/Ownable.sol"; +import "@kaiachain/contracts/utils/Counters.sol"; +contract KIP17NftAirdrop is KIP17, KIP17Enumerable, Ownable { + using Counters for Counters.Counter; + Counters.Counter private _tokenIdCounter; + constructor() KIP17("KIP17 NFT Airdrop", "KNA") {} + // Airdrop NFTs + function airdropNfts(address[] calldata wAddresses) public onlyOwner { + require(wAddresses.length != 0, "Must no be equal to zero"); + for (uint256 i = 0; i < wAddresses.length; i++) { + _mintSingleNFT(wAddresses[i]); + } + } + function _mintSingleNFT(address to) private { + uint256 tokenId = _tokenIdCounter.current(); + _tokenIdCounter.increment(); + _safeMint(to, tokenId); + } + // The following functions are overrides required by Solidity. + function _beforeTokenTransfer(address from, address to, uint256 tokenId) + internal + override(KIP17, KIP17Enumerable) + { + super._beforeTokenTransfer(from, to, tokenId); + } + function supportsInterface(bytes4 interfaceId) + public + view + override(KIP17, KIP17Enumerable) + returns (bool) + { + return super.supportsInterface(interfaceId); + } +} +``` + +從上面修改的代碼中可以看到，我們添加了一個名為 **airdropNfts()** 的新函數。 該函數向某些選定的地址鑄造代幣，並且只能由合約的創建者（onlyOwner）調用。 + +隨後，我們將 **safeMint()** _public onlyOwner_ 函數修改為 **_mintSingleTokens()** **private**。 + +現在我們已經準備好 KIP17 空投合同代碼，下一步是在項目目錄的 src 文件夾中新建一個名為 airdropKIP17.sol 的文件，並將修改後的代碼粘貼到該文件中。 + +**定製 KIP37 合同。** + +由於 KIP37 支持批量鑄幣，我們將只對合同進行定製並按原樣使用。 要定製我們的 KIP37Contract，請按以下步驟操作： + +1. 導航至 [wizard.klaytn.foundation.](https://wizard.klaytn.foundation/) +2. 在**合同**選項卡上選擇**KIP37** +3. 下一步是在**設置**選項卡中填寫名稱（KIP7 NFT Airdrop）和符號（KNA）。 基礎 URI 字段應為空。 +4. 隨後，在**特性**選項卡上，勾選**可編輯**、**自動遞增索引**和**可數**特性框。 您會發現**訪問控制**選項卡中的 "可擁有 "功能已被自動選中。 + +進行這些配置後，Kaia 合同嚮導就會變成這樣： + +![](/img/build/tools/kip37-kcw.png) + +以下是生成的代碼： + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.4; +import "@kaiachain/contracts/KIP/token/KIP37/KIP37.sol"; +import "@kaiachain/contracts/access/Ownable.sol"; +contract KIP37MultiToken is KIP37, Ownable { + constructor() KIP37("") {} + function setURI(string memory newuri) public onlyOwner { + _setURI(newuri); + } + function mint(address account, uint256 id, uint256 amount, bytes memory data) + public + onlyOwner + { + _mint(account, id, amount, data); + } + function mintBatch(address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data) + public + onlyOwner + { + _mintBatch(to, ids, amounts, data); + } +} +``` + +現在我們已經準備好 KIP37 合約代碼，下一步是在項目目錄的 src 文件夾中新建一個名為 KIP37MultiToken.sol 的文件，並將生成的代碼粘貼到其中。 + +為所有 Kaia 合同生成合同代碼後，下一步就是使用 Foundry solidity 腳本部署到 Kaia 測試網 Kairos。 + +## 使用 Foundry 腳本部署生成的智能合約代碼 + +在本節中，我們將使用 Foundry 部署生成的智能合約代碼，特別是在鏈上部署的 Foundry 腳本。 + +### 開始 + +在開始使用鑄造時，您一定初步接觸過使用 [forge create](https://book.getfoundry.sh/reference/forge/forge-create.html)來延遲合同的方法。 最近，Foundry 團隊提出了一種使用 Solidity 聲明式部署合約的更友好方法，稱為 [Solidity Scripting](https://book.getfoundry.sh/tutorials/solidity-scripting#solidity-scripting)，即用 solidity 而不是 JavaScript 編寫部署腳本。 + +在本節中，我們將在 Foundry 中使用 solidity 腳本部署我們的合約。 + +### 環境配置 + +我們將把生成的智能合約部署到 Kaia Kairos 測試網絡，但為此我們需要對 Foundry 進行一些配置，比如設置 Kairos RPC URL、使用 KAIA 測試資金的賬戶私鑰等。 + +完成所有步驟後，創建一個 .env 文件並添加變量。 Foundry 會自動加載項目目錄中的 .env 文件。 + +.env 文件應遵循以下格式： + +```code +KAIROS_RPC_URL= +// 如果要部署到主網 +MAINNET_RPC_URL= +PRIVATE_KEY= +``` + +現在我們需要編輯 `foundry.toml` 文件。 項目根目錄中應該已經有一個。 將以下幾行粘貼到文件末尾 + +```code +[rpc_endpoints] +kairos = "${KAIROS_RPC_URL}" +// 如果要部署到主網 +mainnet = "${MAINNET_RPC_URL}" +``` + +### 編寫劇本 + +接下來，我們必須創建一個文件夾，並將其命名為腳本（如果還不存在的話）。 然後，我們需要為合同創建一個腳本文件，即： +airdropKIP7.s.sol +airdropKIP17.s.sol +KIP37MultiToken.s.sol +這就是我們要編寫的部署腳本。 每個文件的內容應如下所示： + +1. airdropKIP7.s.sol + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; +import "forge-std/Script.sol"; +import "../src/airdropKIP7.sol"; + +contract KIP7AirdropDeployScript is Script { + + function setUp() public {} + + function run() public { + uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY"); + + vm.startBroadcast(deployerPrivateKey); + + KIP7TokenAirdrop kip7TokenAirdrop = new KIP7TokenAirdrop(); + + vm.stopBroadcast(); + } +} +``` + +2. airdropKIP17.s.sol + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; +import "forge-std/Script.sol"; +import "../src/airdropKIP17.sol"; + +contract KIP17AirdropDeployScript is Script { + + function setUp() public {} + + function run() public { + uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY"); + + vm.startBroadcast(deployerPrivateKey); + + KIP17NftAirdrop kip17NftTokenAirdrop = new KIP17NftAirdrop(); + + vm.stopBroadcast(); + } +} +``` + +3. KIP37MultiToken.s.sol + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; +import "forge-std/Script.sol"; +import "../src/KIP37MultiToken.sol"; + +contract KIP37MultiTokenDeployScript is Script { + + function setUp() public {} + + function run() public { + + uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY"); + + vm.startBroadcast(deployerPrivateKey); + + KIP37MultiToken kip37MultiToken = new KIP37MultiToken(); + + vm.stopBroadcast(); + } +} +``` + +讓我們來看看每行代碼的作用。 + +首先，我們為每個腳本文件聲明瞭 SPDX 許可證和 pragma 版本。 請注意，由於每個腳本文件都是一個 solidity 程序，我們仍需聲明 SPDX 許可證和 pragma 版本，使其像智能合約一樣工作，但永遠不會部署。 + +接下來，我們導入 [Forge Std/Script.sol](https://github.com/foundry-rs/forge-std/blob/master/src/Script.sol)，它提供了一些用於部署合同的腳本工具。 隨後，我們導入要部署的合同。 在這種情況下，每個腳本都需要 **airdropKIP7**、**airdropKIP17**、**KIP37MultiToken**。 + +然後，我們為每個腳本文件創建了名為 **KIP7AirdropDeployScript**、**KIP17AirdropDeployScript**、**KIP37MultiTokenDeployScript** 的合約，這些腳本文件繼承了 Forge Std 庫中的腳本。 + +接下來，我們聲明瞭 **run()** 函數。 函數 run() 是執行腳本的入口點。 然後，我們在 +中聲明瞭一個 **deployerPrivateKey** 變量，用於從 .env 文件中加載私鑰。 + +隨後，我們調用了**vm.startBroadcast(deployerPrivateKey)** 特殊作弊代碼，該代碼記錄了主腳本合約的調用和合約創建，並傳遞了用於簽署事務的 deployerPrivateKey。 + +然後，我們創建了相應的合同。 由於我們之前調用了 vm.startBroadcast() 作弊代碼，因此 forge 將記錄此合約創建過程。 + +現在，我們已經對每一行的內容有了大致的瞭解，您可以繼續部署合同了。 點擊此 [鏈接](https://book.getfoundry.sh/tutorials/solidity-scripting#writing-the-script)，瞭解更多關於編寫腳本和其他細節的信息。 + +在項目根部運行 + +```bash +// To load the variables in the .env file +source .env +``` + +要部署每份合同，請運行以下命令： + +1. airdropKIP7 + +```bash +forge script script/airdropKIP7.s.sol:KIP7AirdropDeployScript --rpc-url $KAIROS_RPC_URL --broadcast --skip-simulation -vvvv +``` + +2. airdropKIP17 + +```bash +forge script script/airdropKIP17.s.sol:KIP17AirdropDeployScript --rpc-url $KAIROS_RPC_URL --broadcast --skip-simulation -vvvv +``` + +3. KIP37MultiToken + +```bash +forge script script/KIP37MultiToken.s.sol:KIP37MultiTokenDeployScript --rpc-url $KAIROS_RPC_URL --broadcast -skip-simulation -vvvv +``` + +如果每條命令都執行成功，終端應該如下所示： + +![](/img/build/tools/deploy-kcw-contracts.png) + +請參閱本 [指南](https://book.getfoundry.sh/reference/forge/forge-script)，瞭解有關腳本命令的更多信息。 + +## 結論 + +在本教程中，您將瞭解 Kaia 合同嚮導、其功能以及如何使用 KCW 自定義合同。 本指南還演示瞭如何生成智能合約代碼，以及如何將生成的智能合約代碼作為起點，並通過特定應用邏輯進一步定製。 + +此外，我們還使用 Foundry solidity 腳本將生成的合同部署到 Kaia Kairos Testnet。 您可以使用 Remix IDE 或任何智能合約開發環境來部署從 Kaia Contracts Wizard 派生或定製的智能合約。 您可以在以下鏈接中找到相應的教程： + +- [連接到 Remix](../tutorials/connecting-remix.md#connecting-kaia-remix-using-metamask) +- [使用 Hardhat 部署智能合約](../get-started/hardhat.md) +- [使用 Truffle 部署智能合約](../smart-contracts/samples/erc-20.md#2-2-deploying-smart-contract-using-truffle) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md new file mode 100644 index 000000000000..6e25f1162130 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/kaia-online-toolkit.md @@ -0,0 +1,19 @@ +# Kaia Online Toolkit + +## 什麼是 Kaia 在線工具包？ + +- Kaia在線工具包 "提供代碼示例，幫助您輕鬆使用 "Kaia SDK(caver-js)"。 此外，它還提供了一個 [演示頁面](https://toolkit.klaytn.foundation)，供開發人員使用簡單的在線工具。 +- Kaia SDK(caver-js)\` 是一個 JavaScript API 庫，允許開發人員使用 HTTP 或 Websocket 連接與 Kaia 節點進行交互。 +- 您可以直接試用 Kaia 的功能，而無需編寫代碼。 + +> 為了幫助更多的人使用 "Kaia 在線工具包"，我們編寫了["使用 Kaia 在線工具包"](https://medium.com/klaytn/using-klaytn-online-toolkit-1-multisig-60399a0b0278) 系列。 + +## 鏈接 + +以下是 "Kaia 在線工具包 "的鏈接。 歡迎使用 :) + +- [Github Repository](https://github.com/kaiachain/kaia-online-toolkit) +- [工具包頁面](https://toolkit.kaia.io) +- [Kaia SDK(caver-js)](../../references/sdk/caver-js/caver-js.md) + +![Kaia Online Toolkit](/img/build/tools/klaytn-online-toolkit.png) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md new file mode 100644 index 000000000000..5b9835d3c44c --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/oracles.md @@ -0,0 +1,13 @@ +# 神諭 + +區塊鏈中樞是連接區塊鏈和其他外部數據源的紐帶。 實際上，區塊鏈是一個封閉系統；因此，它無法從任何外部系統（鏈外數據）中獲取數據，只能訪問原始區塊鏈上下文中已經存在的數據。 這就產生了一個區塊鏈-賬本問題，即區塊鏈無法從實際發生的事件中獲取數據。 然而，智能合約必須連接到廣泛的外部數據源，才能實現許多有用的功能。 舉例來說，一個[混合智能合約](https://chain.link/education-hub/hybrid-smart-contracts)可以利用神諭給出金融領域的資產價格、保險領域的天氣數據、遊戲領域的隨機性、供應鏈管理領域的物聯網傳感器等。 + +區塊鏈需要訪問和連接外部數據源、遺留系統和高級計算，這帶來了諭令。 不能低估區塊鏈行業中諭令器的好處，因此在創建混合智能合約時，在選擇諭令器之前進行研究至關重要。 因此，我們鼓勵避免使用中心化算子，因為利用去中心化算子對開發去中心化應用程序非常重要。 一方面，中心化的示權器由單一實體控制，因此存在單點故障，使智能合約容易受到攻擊。 另一方面，分散式計算器的設計消除了單點故障，從而超越了集中式計算器的侷限性。 去中心化甲骨文由點對點網絡中的多個參與者組成，在將鏈外數據發送給智能合約之前，這些參與者會就鏈外數據達成共識。 + +以下提供商已與 Kaia 集成，以提供分散式 Oracle 服務： + +- [Pyth Network](https://docs.pyth.network/home) +- [Orakl Network](https://docs.orakl.network) +- [Witnet](https://docs.witnet.io/) +- [SupraOracles](https://supraoracles.com/docs/overview) +- [KlayOracle](https://klayoracle.gitbook.io/v1.0.0/) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md new file mode 100644 index 000000000000..999563a5cd29 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/orakl-network.md @@ -0,0 +1,208 @@ +# 奧拉克爾網絡 + +![](/img/banners/kaia-orakl.png) + +## 導言 + +[Orakl Network](https://docs.orakl.network) 是一個去中心化的甲骨文網絡，允許智能合約安全地訪問鏈外數據和其他資源。 它引以為豪的是，自己是一個提供 [Data Feed](https://docs.orakl.network/developers-guide/data-feed)、[VRF](https://docs.orakl.network/developers-guide/vrf)、[Request-Response](https://docs.orakl.network/developers-guide/request-response) 和 [Proof of Reserve](https://docs.orakl.network/developers-guide/proof-of-reserve) 解決方案的本地令牌交易系統。 + +有了 Orakl 網絡，用戶可以在智能合約中尋找不可預測、無偏見的隨機性。 Orakl Network [Verifiable Random Function (VRF)](https://docs.orakl.network/developers-guide/vrf#what-is-verifiable-random-function)允許智能合約生成可驗證的隨機值，可用於各種需要隨機性的 dApp。 Orakl Network 通過兩種不同的賬戶類型為開發人員提供 VRF 服務訪問權限，即[永久賬戶](https://docs.orakl.network/developers-guide/readme#permanent-account) 或[臨時賬戶](https://docs.orakl.network/developers-guide/readme#temporary-account)。 + +在本教程中，您將利用 Orakl Network 的 VRF 功能從智能合約內部請求隨機單詞。 + +## 先決條件 + +- [Kaia 錢包](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) +- [Remix IDE](https://remix.ethereum.org/) +- [Kaia Plugin on Remix](https://klaytn.foundation/using-klaytn-plugin-on-remix/) +- 測試來自 [龍頭] 的 KAIA(https://faucet.kaia.io) + +## 開始 + +在以下步驟中，您將使用 Orakl 網絡在智能合約中請求一個隨機單詞。 讓我們開始吧！ + +### 步驟 1：初始化合同狀態變量 + +在這一步中，我們將定義消費者合約，並初始化合約功能所需的狀態變量。 我們的消費者合約依賴於 "VRFConsumerBase "合約和 "IVRFCoordinator "接口，"IVRFCoordinator "接口用於調用 "VRFCoordinator "合約。 接下來，我們定義用於存儲隨機單詞結果的 `sRandomWord` 變量和在 `onlyOwner` 修飾符中使用的 `sOwner` 變量。 + +```solidity +pragma solidity ^0.8.16; + +import { VRFConsumerBase } from "@bisonai/orakl-contracts/src/v0.1/VRFConsumerBase.sol"; +import { IVRFCoordinator } from "@bisonai/orakl-contracts/src/v0.1/interfaces/IVRFCoordinator.sol"; + +contract VRFConsumer is VRFConsumerBase { + uint256 public sRandomWord; + address private sOwner; + + error OnlyOwner(address notOwner); + modifier onlyOwner() { + if (msg.sender != sOwner) { + revert OnlyOwner(msg.sender); + } + _; + } +``` + +### 第 2 步：初始化 VRF 協調器 + +要在智能合約中請求隨機詞語，需要初始化 [`VRFCoordinator`](https://github.com/Bisonai/orakl/blob/master/contracts-v0.1/src/v0.1/VRFCoordinator.sol) 智能合約。 建議將 `VRFCoordinator` 接口與通過構造參數提供的 `VRFCoordinator` 地址綁定，並將其用於隨機單詞請求 (`requestRandomWords`)。 VRFCoordinator "合約同時部署在 Kaia Kairos [0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499](https://kairos.kaiascan.io/account/0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499) 和 Kaia Mainnet [0x3F247f70DC083A2907B8E76635986fd09AA80EFb](https://www.kaiascan.io/account/0x3F247f70DC083A2907B8E76635986fd09AA80EFb) 上。 + +```solidity + IVRFCoordinator COORDINATOR; + + constructor(address coordinator) VRFConsumerBase(coordinator) { + COORDINATOR = IVRFCoordinator(coordinator); + sOwner = msg.sender; + } +``` + +### 步驟 3：使用臨時賬戶申請隨機詞語 + +要使用臨時賬戶申請隨機詞語，用戶需要發送 $KAIA 並使用 value 屬性調用。 + +```solidity + function requestRandomWordsDirect( + bytes32 keyHash, + uint32 callbackGasLimit, + uint32 numWords, + address refundRecipient + ) + public + payable + onlyOwner + returns (uint256 requestId) + { + requestId = COORDINATOR.requestRandomWords{value: msg.value}( + keyHash, + callbackGasLimit, + numWords, + refundRecipient + ); + } +``` + +該函數調用 `COORDINATOR` 合約中定義的 `requestRandomWords()` 函數，並將 `keyHash`, `callbackGasLimit`, `numWords` 和 `refundRecipient` 作為參數傳遞。 服務費通過 `msg.value` 發送給 `COORDINATOR` 合約中的 `requestRandomWords()` 。 如果付款額大於預期付款額，超出部分將退回到 `refundRecipient` 地址。 最終，它會生成一個隨機詞語請求。 要準確指定 "requestRandomWords "函數的 "msg.value"，請參閱[如何估算服務費](https://docs.orakl.network/developers-guide/vrf#get-estimated-service-fee)的說明。 + +### 步驟 4：填寫隨機詞語 + +滿足隨機詞語請求時，`VRFCoordinator`合約會調用`fulfillRandomWords`函數。 + +```solidity +function fulfillRandomWords( + uint256 /* requestId */, + uint256[] memory randomWords +) + internal + override +{ + // requestId should be checked if it matches the expected request + // Generate random value between 1 and 50. + sRandomWord = (randomWords[0] % 50) + 1; +} +``` + +現在我們有了 Orakl VRF 解決方案的代碼，讓我們來看看它的實際操作。 + +## 具體實施 + +在下面的示例中，合同允許我們請求隨機詞語並得到滿足。 + +### 創建和部署示例代碼 + +**Remix IDE** + +- 導航至 [Remix IDE](https://remix.ethereum.org/)。 +- 單擊**文件資源管理器**選項卡，在合同文件夾中新建一個名為 "consumer-vrf.sol "的文件。 +- 將下面的代碼粘貼到新創建的文件中。 +- 在 Remix 中，點擊 **編譯合同**。 +- 安裝插件後，點擊左側的 Kaia 選項卡。 +- 選擇 **環境** > **注入式提供商** - **Kaia Wallet**。 +- 在**合同**中，選擇您的合同。 例如，`VRFConsumer`。 +- 輸入協調者合約地址 `0xDA8c0A00A372503aa6EC80f9b29Cc97C454bE499` (Kairos), `0x3F247f70DC083A2907B8E76635986fd09AA80EFb` (Mainnet). +- 點擊 **部署**。 + +\*\* 示例代碼\*\* + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.16; + +import {VRFConsumerBase} from "@bisonai/orakl-contracts/src/v0.1/VRFConsumerBase.sol"; +import {IVRFCoordinator} from "@bisonai/orakl-contracts/src/v0.1/interfaces/IVRFCoordinator.sol"; + +contract VRFConsumer is VRFConsumerBase { + uint256 public sRandomWord; + address private sOwner; + + IVRFCoordinator COORDINATOR; + + error OnlyOwner(address notOwner); + + modifier onlyOwner() { + if (msg.sender != sOwner) { + revert OnlyOwner(msg.sender); + } + _; + } + + constructor(address coordinator) VRFConsumerBase(coordinator) { + sOwner = msg.sender; + COORDINATOR = IVRFCoordinator(coordinator); + } + + function requestRandomWordsDirect( + bytes32 keyHash, + uint32 callbackGasLimit, + uint32 numWords, + address refundRecipient + ) public payable onlyOwner returns (uint256 requestId) { + requestId = COORDINATOR.requestRandomWords{value: msg.value}( + keyHash, + callbackGasLimit, + numWords, + refundRecipient + ); + } + + function fulfillRandomWords( + uint256 /* requestId */, + uint256[] memory randomWords + ) internal override { + // requestId should be checked if it matches the expected request + // Generate random value between 1 and 50. + sRandomWord = (randomWords[0] % 50) + 1; + } +} +``` + +![](/img/build/tools/orakl-vrf-deploy.png) + +### 與智能合約互動 + +要在智能合約中請求隨機詞語，必須先執行 `requestRandomWordsDirect()` 函數。 要成功執行該函數，用戶必須如前所述發送 KAIA（最少 1 KAIA），並提供 `keyHash`, `callbackGasLimit`, `numWords` 和 `refundRecipient` 參數。 keyHash\` 參數唯一定義了誰可以執行請求。 Orakl Network VRF 為每個 Kaia 鏈提供一個密鑰哈希值： + +- Kairos: `0xd9af33106d664a53cb9946df5cd81a30695f5b72224ee64e798b278af812779c` +- Mainnet: `0x6cff5233743b3c0321a19ae11ab38ae0ddc7ddfe1e91b162fa8bb657488fb157` + +其餘參數的設置方法如下： + +- callbackGasLimit "為 "500000"、 +- 字數 "為 "1"，以及 +- 將 `refundRecipient` 設為您的 EOA 地址。 + +之後，一旦請求得到滿足，就可以執行`sRandomWord()`函數。 該 `sRandomWord()` 函數返回隨機單詞。 + +- **requestRandomWordsDirect()**：將發送 1 個 KAIA 以執行此函數。 下面的圖片說明瞭這一點： + +![](/img/build/tools/orakl-vrf-request.png) + +- **sRandomWord()**：在 `VRFCoordinator` 完成隨機字請求後，響應將存儲在 `sRandomWord` 變量中。 要獲取響應，請調用`sRandomWord()`函數。 + +![](/img/build/tools/orakl-vrf-response.png) + +塔達 🎉！ 您剛剛請求了一個隨機單詞，並在智能合約中收到了一個。 + +## 結論 + +在本教程中，您將學習如何使用 Orakl Network VRF 解決方案在智能合約中生成隨機單詞。 Orakl 網絡提供更多甲骨文服務，如數據反饋、請求-響應、儲備證明。 有關 Orakl Network 及其工作原理的更多深入指南，請參閱 [Orakl Network 文檔](https://docs.orakl.network)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md new file mode 100644 index 000000000000..8b7f9395767b --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/pyth-network.md @@ -0,0 +1,82 @@ +# Pyth 網絡 + +![](/img/banners/kaia-pyth.png) + +## 概述 + +Pyth 網絡](https://pyth.network/) 是最大的甲骨文第一方網絡之一，提供[大量連鎖店](https://docs.pyth.network/price-feeds/contract-addresses) 的即時數據。 + +該網絡由全球[最大的交易所、做市商和金融服務提供商]組成(https://pyth.network/publishers)。 這些數據在鏈上發佈專有數據，供智能合約應用程序彙總和分發。 + +## 使用 Pyth 網絡 + +Pyth 引入了創新的低延遲[拉動式甲骨文設計](https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand)，用戶可以在需要時拉動鏈上的價格更新，使鏈上環境中的每個人都能最高效地訪問該數據點。 Pyth 網絡每**400毫秒**更新一次價格，使 Pyth 成為速度最快的鏈上算子之一。 + +Kaia 上的開發人員可以無權限地訪問股票、ETF、商品、外匯貨幣對和加密貨幣的任何 [Pyth's price feeds](https://pyth.network/developers/price-feed-ids)。 + +下面是一個在 Kaia 網絡上獲取 ETH/USD 最新價格的合約示例。 +您必須通過[Pyth 的合約地址](https://docs.pyth.network/price-feeds/contract-addresses/evm) 獲取 Kaia 主網/主網的信息，並通過所需的[price feed id](https://pyth.network/developers/price-feed-ids)獲取最新價格。 + +```solidity +// SPDX-License-Identifier: UNLICENSED +pragma solidity ^0.8.13; + +import "@pythnetwork/pyth-sdk-solidity/IPyth.sol"; +import "@pythnetwork/pyth-sdk-solidity/PythStructs.sol"; + +contract MyFirstPythContract { + IPyth pyth; + + constructor(address _pyth) { + pyth = IPyth(_pyth); + } + + function fetchPrice( + bytes[] calldata updateData, + bytes32 priceFeed + ) public payable returns (int64) { + // Fetch the priceUpdate from hermes. + uint updateFee = pyth.getUpdateFee(updateData); + pyth.updatePriceFeeds{value: updateFee}(updateData); + + // Fetch the latest price + PythStructs.Price memory price = pyth.getPrice(priceFeed); + return price.price; + } +} +``` + +在這裡，你可以從我們的[`Hermes`](https://hermes.pyth.network/docs/)獲取`updateData`，它監聽 Pythnet 和 Wormhole 以獲取價格更新；或者你也可以使用[`pyth-evm-js`](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/js/src/EvmPriceServiceConnection.ts#L15) SDK。 查看 [如何獲取價格更新](https://docs.pyth.network/price-feeds/fetch-price-updates) 獲取最新數據。 + +該[軟件包](https://github.com/pyth-network/pyth-crosschain/tree/main/target_chains/ethereum/sdk/solidity) 提供了使用 Solidity 從 Pyth 網絡甲骨文中獲取價格的實用工具。 此外，它還包含[Pyth Interface ABI](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/solidity/abis/IPyth.json)，您可以在庫中使用它與 Pyth 合約通信。 + +我們建議在使用 Pyth 數據時遵循 [用戶最佳實踐](https://docs.pyth.network/documentation/pythnet-price-feeds/best-practices)。 + +更多信息，請查閱官方 [Pyth 文檔](https://docs.pyth.network/price-feeds)。 有關與 Pyth 智能合約交互的各種功能的詳細信息，請參見[API 參考部分](https://api-reference.pyth.network/price-feeds/evm/getPrice)。 + +## Pyth on Kaia + +Pyth Network 智能合約可在以下地址獲取： + +- 主網：[0x2880ab155794e7179c9ee2e38200202908c17b43](https://kaiascan.io/account/0x2880aB155794e7179c9eE2e38200202908C17B43) +- Kairos Testnet：[0x2880ab155794e7179c9ee2e38200202908c17b43](https://kairos.kaiascan.io/account/0x2880aB155794e7179c9eE2e38200202908C17B43) + +此外，單擊可訪問 [Pyth 價格-進價 ID](https://pyth.network/developers/price-feed-ids)。 + +## 將 Pyth 用作 PUSH Oracle + +Pyth Oracle 可用作推送甲骨文，通過運行一個調度程序來更新後臺的價格。 它將確保您的 dapp 根據您的配置更新最新價格。 查看開源 [price pusher](https://github.com/pyth-network/pyth-crosschain/tree/main/apps/price_pusher) 應用程序，開始使用調度程序。 + +## 開發商和社區 + +Pyth 網絡為開發人員提供了更多工具，如 [TradingView Integration](https://docs.pyth.network/guides/how-to-create-tradingview-charts) 或 [Gelato web3 functions](https://docs.pyth.network/guides/how-to-schedule-price-updates-with-gelato) 等。 + +查看以下鏈接，開始使用 Pyth。 + +- [Pyth EVM 集成指南](https://docs.pyth.network/price-feeds/use-real-time-data/evm) +- [Pyth文檔](https://docs.pyth.network/home) +- [Pyth API 參考](https://api-reference.pyth.network/price-feeds/evm/getPrice) +- [Pyth 示例](https://github.com/pyth-network/pyth-examples) +- [Pyth Price Feed Ids](https://pyth.network/developers/price-feed-ids) +- [Website](https://pyth.network/) +- [Twitter](https://x.com/PythNetwork) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md new file mode 100644 index 000000000000..768296a2c457 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/supraoracles.md @@ -0,0 +1,148 @@ +# SupraOracles + +![](/img/banners/kaia-supra.png) + +## 導言 + +[SupraOracles](https://supraoracles.com/)是一種新穎、高吞吐量的 Oracle & IntraLayer：一種垂直整合的跨鏈解決方案工具包（數據oracles、資產橋、自動化網絡等），可將所有區塊鏈（公有鏈（L1s 和 L2s）或私有鏈（企業））相互連接起來。 它為智能合約提供了下一代跨鍊甲骨文解決方案，具有卓越的數據準確性、速度、可擴展性和安全性。 + +有了 SupraOracles，您的智能合約就可以訪問價格數據源，從而構建各種去中心化金融（DeFi）用例。 在本教程中，您將使用 SupraOracles，使用 Remix IDE 在 Kaia 區塊鏈上輕鬆獲取價格信息。 + +## 先決條件 + +- [Kaia 錢包](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) +- [Remix IDE](https://remix.ethereum.org/) +- [Kaia Plugin on Remix](https://klaytn.foundation/using-klaytn-plugin-on-remix/) +- 測試來自 [龍頭] 的 KAIA(https://faucet.kaia.io) + +## 開始 + +在以下步驟中，您將使用 SupraOracles 在智能合約中請求 ETH/USD 價格反饋。 讓我們開始吧！ + +### 步驟 1：創建 S 值接口 + +這將創建用於從 SupraOracles 獲取價格的接口。 將以下代碼添加到您希望獲取 S 值的 solidity 智能合約中。 + +```solidity +interface ISupraSValueFeed { +function checkPrice(string memory marketPair) external view returns (int256 price, uint256 timestamp); +} +``` + +### 步驟 2：配置 S 值反饋地址 + +要從 SupraOracles 智能合約中獲取 S-Value，首先要找到所選鏈的 S-Value Feed 地址。 有了正確的地址後，使用我們之前定義的接口創建一個 S-Value Feed 實例： + +```solidity +contract ISupraSValueFeedExample { + ISupraSValueFeed internal sValueFeed; + constructor() { + sValueFeed = ISupraSValueFeed(0x7f003178060af3904b8b70fEa066AEE28e85043E); + } +} +``` + +在本例中，我們在 Kaia Kairos TestNet 上實現了 S-Value Feed。 您可以在 [此處](https://supraoracles.com/docs/get-started/networks/) 驗證 Kaia Kairos S-Value Feed 地址。 + +### 第 3 步：獲取 S-Value 加密貨幣價格 + +現在，您只需訪問我們支持的市場貨幣對的 S-Value Crypto 價格即可。 在這一步中，您將在智能合約中應用以下代碼，從而獲得 ETH/USDT (eth_usdt) 的價格。 + +```solidity +function getEthUsdtPrice() external view returns (int) { +( +int price, +/* uint timestamp */ +) = sValueFeed.checkPrice("eth_usdt"); +return price; +} +``` + +## 具體實施 + +在下面的示例中，我們將部署 S-Value 價格反饋合約，同時執行 getEthUsdtPrice() 函數來獲取 ETH/USDT 貨幣對的價格。 + +### 創建和部署示例代碼 + +**Remix IDE** + +- 導航至 [Remix IDE](https://remix.ethereum.org/) +- 單擊 "文件資源管理器 "選項卡，在合同文件夾中新建一個名為 "demoSupraPriceFeed.sol "的文件。 +- 將下面的代碼粘貼到新創建的文件中 +- 在 Remix 中，點擊 **編譯合同**。 +- 安裝插件後，點擊左側的 Kaia 選項卡 +- 選擇 **環境** > **注入式提供商** - **Kaia Wallet**。 +- 在**合同**中，選擇您的合同。 例如，ISupraSValueFeedExample。 +- 點擊 **部署**。 + +\*\* 示例代碼\*\* + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.7; +interface ISupraSValueFeed { + function checkPrice(string memory marketPair) external view returns (int256 price, uint256 timestamp); +} +contract ISupraSValueFeedExample { + ISupraSValueFeed internal sValueFeed; + constructor() { + sValueFeed = ISupraSValueFeed(0x7f003178060af3904b8b70fEa066AEE28e85043E); + } + function getEthUsdtPrice() external view returns (int) { + ( + int price, + /* uint timestamp */ + ) = sValueFeed.checkPrice("eth_usdt"); + return price; + } +} +``` + +### 與智能合約互動 + +要獲取所選貨幣對的價格信息，必須執行`getEthUsdtPrice()`函數。 + +![](/img/build/tools/sPriceFeed.png) + +塔達 🎉！ 您剛剛請求在智能合約中提供貨幣價格（ETH/USDT）。 + +截至編寫本報告時，getEthUsdtPrice() 返回了 "185795966200"，一個 8 點精度的數字。 要獲得 ETH/USD 的實際價值，您需要將該數字除以 10^8，等於 1857.95966200 美元。 + +## 使用 SupraOracles Crypto Price Feeds 的更多方法 + +### 使用 Web3.js 實現 S-Value Feeds + +```javascript +// example assumes that the web3 library has been imported and is accessible within your scope +const getEthUsdtPrice = async () => { +const abi = [{ "inputs": [ { "internalType": "string", "name": "marketPair", "type": "string" } ], "name": "checkPrice", "outputs": [ { "internalType": "int256", "name": "price", "type": "int256" }, { "internalType": "uint256", "name": "timestamp", "type": "uint256" } ], "stateMutability": "view", "type": "function" } ] +const address = '0x7f003178060af3904b8b70fEa066AEE28e85043E' +const web3 = new Web3('https://public-en-kairos.node.kaia.io') +const sValueFeed = new web3.eth.Contract(abi, address) +const price = (await sValueFeed.methods.checkPrice('eth_usdt').call()).price +console.log(`The price is: ${price}`) +} +getEthUsdtPrice() +``` + +### 使用 ethers.js 的 S-Value Feeds + +```javascript +// example assumes that the ethers library has been imported and is accessible within your scope +const getEthUsdtPrice = async () => { +////for ethers version 6.0 +const provider = new ethers.JsonRpcProvider("https://public-en-kairos.node.kaia.io") +////for ethers version <= 5.7.2 +//const provider = new ethers.providers.JsonRpcProvider('https://public-en-kairos.node.kaia.io') +const abi = [{ "inputs": [ { "internalType": "string", "name": "marketPair", "type": "string" } ], "name": "checkPrice", "outputs": [ { "internalType": "int256", "name": "price", "type": "int256" }, { "internalType": "uint256", "name": "timestamp", "type": "uint256" } ], "stateMutability": "view", "type": "function" } ] +const address = '0x7f003178060af3904b8b70fEa066AEE28e85043E' +const sValueFeed = new ethers.Contract(address, abi, provider) +const price = (await sValueFeed.checkPrice('eth_usdt')).price +console.log(`The price is: ${price.toString()}`) +} +getEthUsdtPrice() +``` + +## 結論 + +在本教程中，您將學習如何使用 SupraOracle 價格饋送解決方案請求 ETH/USD 價格。 有了 SupraOracle，您還可以在智能合約中生成隨機數。 如果您想了解這一過程，請訪問有關在 Kaia 上集成 SupraVRF 的 [指南](https://metaverse-knowledge-kit.klaytn.foundation/docs/decentralized-oracle/oracle-providers/supraOracles-tutorial)。 有關 SupraOracles 的更多深入指南，請參閱 [SupraOracles 文檔](https://supraoracles.com/docs/development-guides)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md new file mode 100644 index 000000000000..9fb433328645 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/oracles/witnet.md @@ -0,0 +1,15 @@ +# Witnet + +![](/img/banners/kaia-witnet.png) + +## 導言 + +Witnet](https://docs.witnet.io/) 多鏈去中心化甲骨文使智能合約能夠訪問各種有價值的外部數據集，從而發揮其潛力。 這些有價值的數據集包括體育比賽成績、股票價格、天氣預報、隨機性等。 +為了提供去中心化的甲骨文服務，Witnet 依賴於一個由對等節點（俗稱證人）組成的分佈式網絡，這些節點通過檢索網絡數據並將其直接報告給智能合約來賺取 Wit 代幣作為獎勵。 見證人負責尋找、檢索和驗證數據集。 為確保透明度，每個匿名同行都會受到激勵，如實報告檢索到的數據，並對任何錯誤行為進行懲罰或削減。 + +## 使用方法 + +該甲骨文網絡目前在 Kaia 主網和 Kaia Kairos 測試網上運行。 要開始連接 Kaia 上的數據源和隨機性，請參閱以下指南： + +- [Witnet價格饋送教程](https://metaverse-knowledge-kit.klaytn.foundation/docs/decentralized-oracle/oracle-providers/witnet-tutorial) +- [利用 Witnet 在 Kaia 上生成隨機數](https://medium.com/klaytn/random-number-generation-on-klaytn-with-witnet-ae136dad0562) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/tools.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/tools.md new file mode 100644 index 000000000000..48d000851136 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/tools.md @@ -0,0 +1,9 @@ +# 工具 + +本頁包含開發工具列表，可幫助您在 Kaia 上構建去中心化應用程序。 + +```mdx-code-block +import DocCardList from '@theme/DocCardList'; + + +``` diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md new file mode 100644 index 000000000000..6dc1c9c49a74 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/dcent.md @@ -0,0 +1,13 @@ +# D'cent 生物識別錢包 + +## 導言 + +D'Cent Wallet 是一款非託管生物識別錢包，旨在提供支持藍牙的硬件和軟件選項，讓您輕鬆管理加密貨幣。 + +在其[官方網站](https://store.dcentwallet.com/pages/dcent-biometric-crypto-wallet) 獲取 D'CENT 設備 + +## 指南 + +- [設置](https://userguide.dcentwallet.com/biometric-wallet/setting-up) +- [如何發送和接收 Kaia](https://userguide.dcentwallet.com/coin-send-receive/coins/klaytn-klay#how-to-create-an-klay-account) +- [與 Kaia 錢包連接](https://userguide.dcentwallet.com/external-service/kaikas) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md new file mode 100644 index 000000000000..f83930e3e3e5 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/hardware-wallets/safepal-s1.md @@ -0,0 +1,107 @@ +# SafePal S1 + +![](/img/banners/kaia-safepal.png) + +## 導言 + +硬件錢包重新發明瞭輪子，將私鑰（簽署交易時需要）保存在與互聯網連接分離的離線環境中，避免了依賴互聯網連接的軟件錢包所帶來的大量黑客攻擊或威脅。 這樣，用戶的加密資產就更安全了，也不會受到軟件錢包帶來的網絡危險的影響。 + +與 Kaia 集成的硬件錢包之一是 **SafePal S1 硬件錢包**。 SafePal S1 是一款加密貨幣硬件錢包，旨在為大眾提供一個安全、簡單、愉快的加密貨幣管理解決方案。 SafePal 是一款硬件錢包，用於保護和管理加密貨幣和 NFT，如比特幣、KAIA、Kaia Compatible Tokens(KCT)、以太幣和 ERC20 代幣等。 + +在本指南中，您將 + +- 使用 SafePal S1 硬件錢包添加、接收和發送 Klay 以及任何 Kaia 兼容代幣（KCT） + +## 先決條件 + +- [SafePal 硬件錢包設置](https://safepalsupport.zendesk.com/hc/en-us/articles/360046051752) + +## 入門 + +在成功設置錢包後，接下來就是查看錢包的運行情況了。 在本教程中，我們將使用 SafePal S1 硬件錢包添加、接收和發送 KAIA 原生代幣以及任何 Kaia 兼容代幣（KCT）。 + +### 添加 KAIA 原生硬幣 + +請按照以下步驟將 KAIA 原生幣添加到您的硬件錢包中： + +**第一步**：打開安全寶應用程序，在 "錢包 "選項卡中點擊省略號圖標，然後點擊 "管理硬幣 "按鈕，如下圖所示： + +![](/img/build/tools/step1-add-klay.png) + +**步驟 2**：選擇要添加的硬幣（本例中為 KAIA），然後點擊底部的**添加硬幣**。 + +![](/img/build/tools/step2-add-klay.png) + +**第 3 步**： 在應用程序和 S1 硬件錢包之間來回掃描，以便在應用程序和設備之間正確同步數據。 + +**第 4 步**：成功添加硬幣後，您就可以在 S1 設備上的 "資產管理 "標籤中查看它們了。 + +![](/img/build/tools/step4-add-klay.png) + +請注意，上述步驟適用於添加任何 Kaia 兼容令牌。 + +### 接收 KAIA 原生硬幣 + +成功添加硬幣（KAIA、KCT）後，您可以在 S1 設備上的 "資產管理 "\*\* 標籤中查看它們。 您可以使用以下方法接收 KAIA 本地硬幣： + +#### 使用掌上安全應用程序 + +1. 選擇 KAIA，可選擇交換、接收和發送，點擊接收 +2. 您可以為錢包複製 KAIA 地址，保存二維碼，或讓對方掃描您手機上的二維碼。 + +#### 使用安全寶 S1 硬件錢包 + +**第 1 步** 啟動 SafePal S1 設備，導航至 "資產管理 + +**第 2 步** 選擇 KAIA 作為您希望從他人處接收的硬幣。 + +**第 3 步** 點擊 "接收 "按鈕 + +步驟 4\*\*\*\* 輸入 S1 設備的 PIN 碼。 + +**第 5 步** 然後，您可以查看硬幣地址的二維碼，並將其展示給他人，以便他們掃描並將硬幣發送給您。 + +![](/img/build/tools/sphw-rec-banner.png) + +請注意，上述步驟適用於接收任何 Kaia 兼容代幣。 + +### 發送 KAIA 原生硬幣 + +要從您的硬件錢包發送 KAIA 原生幣，請按照以下步驟操作： + +**第1步** 在安全寶應用程序上，選擇您要發送的硬幣（在我們的例子中為KAIA），然後點擊**發送**。 + +![](/img/build/tools/step1-send-klay.png) + +**第 2 步** 輸入目的地地址和金額，然後點擊 "下一步 "再次確認詳細信息。 確保在此步驟中驗證您的轉賬詳情。 + +![](/img/build/tools/step2-send-klay.png) + +步驟 3\*\*\*\* 啟動 S1 設備的簽署程序。 + +在此步驟中，安全寶應用程序上將顯示一個包含轉賬詳情的 QR 碼（如下圖所示）。 啟動 S1 硬件錢包，進入**掃描**選項卡。 下一步是掃描 SafePal 應用程序上的 QR 碼。 這樣做可確保 S1 設備在脫機環境下接收傳輸詳細信息。 + +![](/img/build/tools/step3-send-klay.png) + +**第 4**步 在 S1 設備上籤署轉讓協議 + +成功掃描轉賬詳情後，您將在 S1 設備上看到轉賬詳情（金額、費用、加油限額等）。 接下來是驗證詳細信息並輸入 PIN 碼。 + +![](/img/build/tools/step4-send-klay.png) + +**第 5 步** 將簽名同步回安全寶應用程序 + +在 S1 設備上成功簽署傳輸後，您將看到一組動態 QR 碼顯示在 S1 設備上。 在安全寶應用程序中，點擊 "下一步 "打開手機攝像頭。 使用 SafePal 應用程序掃描 S1 設備上顯示的動態 QR 碼。 + +這樣做可以確保應用程序收到二維碼中包含的簽名，並準備好向區塊鏈（Kaia）廣播轉賬。 + +步驟 6\*\*\*\* 點擊應用程序上的**廣播**，等待傳輸完成 + +![](/img/build/tools/step6-send-klay.png) + +請注意，上述步驟適用於發送任何 Kaia 兼容令牌。 + +## 更多參考資料 + +- [SafePal S1 升級說明](https://www.safepal.com/en/upgrade/s1) +- [SafePal S1 用戶手冊](https://docs.safepal.io/safepal-hardware-wallet/user-manual) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md new file mode 100644 index 000000000000..4866a96201c5 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/contract-interaction.md @@ -0,0 +1,27 @@ +# 與合同互動 + +在本節中，您將使用我們新創建的多重簽名錢包與部署在 Kairos 上的簡單合約進行交互並向其發送一筆交易。 + +**先決條件** + +- [Metamask](https://metamask.io/download/) & [Kaia Metamask Config](../../../tutorials/connecting-metamask.mdx#send-klay) +- [混音](https://remix.ethereum.org/) 和[Kaia 混音插件](https://klaytn.foundation/using-klaytn-plugin-on-remix/) +- 從 [水龍頭](https://faucet.kaia.io) 獲取測試 KAIA + +**步驟 1：** 導航至 [混音](https://remix.ethereum.org/) + +**第 2 步：** 編譯並部署**存儲合同**示例。 + +必須先部署合約，然後才能在多重簽名錢包中與之交互。 該示例合約包含一個簡單的 uint "數字 "變量，可通過調用**store**方法進行更新，也可通過調用**retrieve**方法進行檢索。 + +![](/img/build/tools/kaia-safe/ks-ic-deploy.gif) + +**第 3 步：** 啟動新交易。 + +要與安全錢包中的智能合約互動，請點擊\*\*"新建交易 "\*\*。 要完成這一步驟，您需要已部署的合同地址和 ABI，如上一步所示。 + +![](/img/build/tools/kaia-safe/kaia-safe-ci-init.gif) + +**第 4 步：** 審查並提交交易。 您需要用簽名者錢包簽署交易，一旦達到確認閾值，交易就會執行。 + +![](/img/build/tools/kaia-safe/kaia-safe-ci-review-send.gif) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/csv-airdrop.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/csv-airdrop.md new file mode 100644 index 000000000000..57dd3d6e8001 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/csv-airdrop.md @@ -0,0 +1,70 @@ +# Use CSV Airdrop + +This is a custom app in Kaia Safe that can be used to batch multiple transfers of ERC20, ERC721, ERC1155 and native tokens into a single transaction. It's as simple as uploading / copy & pasting a single CSV transfer file and hitting the submit button. + +This single method saves gas ⛽ and a substantial amount of time ⌚ by requiring less signatures and transactions. + +Let’s get started with an example using CSV Airdrop! + +## Step 1: Login into your [KaiaSafe](https://safe.kaia.io/) + +If you haven't created a Safe account yet, please refer to our [Create a Safe Guide](./use-kaia-safe.md#create-a-safe) and [Add Asset Guide](./use-kaia-safe.md#add-assets) to set up your account and add assets (KAIA, FT, NFT). + +## Step 2: Click apps, search CSV and select CSV Airdrop + +![](/img/build/tools/kaia-safe/search-csv-app.png) + +## Step 3: Prepare a Transfer CSV file + +Transfer files are expected to be in CSV format with the following required columns: + +- _token_type_: The type of token that is being transferred. One of erc20,nft or native. NFT Tokens can be either ERC721 or ERC1155. +- _token_address_: Ethereum address of ERC20 token to be transferred. This has to be left blank for native (ETH) transfers. +- _receiver_: Ethereum address of transfer receiver. +- _amount_: the amount of token to be transferred. This can be left blank for erc721 transfers. +- _id_: The id of the collectible token (erc721 or erc1155) to transfer. This can be left blank for native and erc20 transfers. + +:::important +The CSV file has to use "," as a separator and the header row always has to be provided as the first row and include the described column names. +[Sample Transfer File](https://ipfs.io/ipfs/bafybeiesr6b3cm76ofcm2joukgdtuyva3niftmbpbb4sgxsa3qwsenv3lu/sample.csv) +::: + +### Native Token Transfers + +Since native tokens do not have a token address, you must leave the _token_address_ column blank for native transfers. + +![](/img/build/tools/kaia-safe/native-csv-app.png) + +:::note +Make sure you have enough native tokens in the kaia safe wallet address. +::: + +### ERC-20 Transfers + +Provide erc20 as _token_type_ for erc20 transfers and other respective fields accordingly. + +![](/img/build/tools/kaia-safe/erc20-csv-app.png) + +:::note +Make sure you have enough erc20 tokens in the kaia safe wallet address. +::: + +### ERC-721 Transfers + +Provide erc721 as _token_type_ for erc721 transfers and other respective fields accordingly. + +![](/img/build/tools/kaia-safe/erc721-csv-app.png) + +:::note +Make sure you have enough erc721 tokens in the kaia safe wallet address. +::: + +### Illustration + +For this illustration, we have 2 native transfers, 2 ERC20 transfers and 1 ERC721 transfers + +![](/img/build/tools/kaia-safe/rs-csv-app.png) + +## Step 4: Review and submit transaction + +You'll be able to review and confirm the transaction. Once ready, click Submit to execute the transaction just like any other Safe transaction. diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md new file mode 100644 index 000000000000..a16794bf653a --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/faqs.md @@ -0,0 +1,106 @@ +# Frequently Asked Questions + +## 創建保險箱後可以添加新的所有者嗎？ + +是的！ 創建保險箱賬戶後，Kaia Safe 會為您提供管理保險箱所有者的權限，即添加、刪除、替換所有者或重命名現有所有者。 + +注意：要執行此更改，您需要與當前所有者之一建立聯繫。 + +下面的步驟說明瞭如何在創建 Safe 賬戶後為其添加新的所有者或簽名人。 + +**步驟 1：** 進入側邊欄菜單的**設置**，你會看到**設置**部分下的**管理安全賬戶簽署人**卡。 + +**步驟 2：** 點擊卡片底部的**添加新簽名人**按鈕。 點擊該按鈕將打開一個新窗口。 + +![](/img/build/tools/kaia-safe/ks-add-signers.png) + +**第 3 步：** 輸入新所有人的**姓名**，並粘貼**所有人的地址**。 然後點擊頁面右下角的 "下一步 "按鈕。 + +**步驟 4：** 設置新的簽名策略。 在這種情況下，您可以更改或保留現有的簽名策略。 下圖顯示，在 4 位所有者中，有 2 位需要確認和執行任何交易。 + +![](/img/build/tools/kaia-safe/ks-add-signer-details.png) + +**第 5 步：** 審查並提交交易。 + +確認所有更改無誤後再提交。 因此，您可以點擊**提交**按鈕來提交更改。 + +點擊**提交**後，連接的錢包會要求您確認更改。 根據現有的簽名政策，其他所有者必須像正常交易一樣確認更改。 + +![](/img/build/tools/kaia-safe/kaia-safe-change-owner-setup-review.gif) + +## 我可以更改所需的簽名確認人數嗎？ + +是的！ 您可以按照以下步驟更改所需的簽名確認次數。 這一點很重要，因為您可能想更改確認與安全賬戶相關的交易所需的所有者或簽名人。 + +**步驟 1：** 進入側邊欄菜單的**設置**，你會看到**設置**部分下的**所需確認**卡。 + +這顯示了您當前的簽名政策，從下圖中可以看出，任何交易都需要 4 位所有者中的 2 位進行確認。 + +![](/img/build/tools/kaia-safe/ks-conf-policy.png) + +**步驟 2：** 單擊 \*\* 更改 \*\* 按鈕。 + +這時會彈出一個新窗口，選擇新的簽名閾值。 + +![](/img/build/tools/kaia-safe/ks-conf-policy-btn.png) + +**步驟 3：** 點擊**提交**按鈕。 + +請注意，根據您現有的簽名政策，其他所有者必須像正常交易一樣確認更改。 + +## 如何添加現有保險箱？ + +導出的 Safe 數據包含已添加的 Safe 賬戶、通訊錄和設置，使用這些數據，您可以輕鬆添加 Safe 賬戶。 + +> 注意：您必須已下載 Safe 數據，如下圖所示： + +![](/img/build/tools/kaia-safe/ks-export-btn.png) + +在界面中添加或加載現有保險箱的需求各不相同。 這些可能包括 + +- 您想從其他瀏覽器訪問 Safe。 +- 您希望與 Safe 進行互動，而另一方讓您成為 Safe 的所有者。 +- 您希望以只讀模式添加任何現有的保險箱。 + +讓我們通過以下步驟來瞭解添加現有保險箱的過程。 注意：請確保簽名者的錢包已連接。 + +**步驟 1：** 導航至**設置**選項卡。 + +**步驟 2：** 滾動到**數據**部分下的**數據導入**卡。 + +![](/img/build/tools/kaia-safe/ks-data-import-i.png) + +在這裡，你可以拖放 JSON 文件，也可以選擇你的文件，如上圖所示。 + +**第 3 步：** 單擊**導入**按鈕。 + +![](/img/build/tools/kaia-safe/ks-data-import-btn.png) + +![](/img/build/tools/kaia-safe/kaia-safe-data-import.gif) + +之後，您就可以訪問 Safe 賬戶了。 + +## 普通安全設置 + +這往往會為建立保險箱時的決策提供一些指導。 這些可能包括 + +- 有多少業主？ + +- 什麼門檻？ + +- 兼容哪些錢包？ + +這三個問題沒有一個最佳答案，因此也就沒有一個最佳的 Safe 配置。 實際上，這完全取決於具體的使用情況。 儘管如此，我們還是努力提出一些建議，供大家參考： + +\*\*有多少業主？ + +通常情況下，擁有多個所有者賬戶是一個明智的選擇。 在團體管理資金時，良好的做法是幾個人都能使用安全賬戶。 建議管理資金的個人擁有多個賬戶，以便使用多個身份驗證因素。 + +\*\*什麼門檻？ + +安全閾值是指在交易成功執行前必須獲得批准的最小所有者賬戶數量。 建議使用大於 1 的閾值，以確保始終需要至少一個額外賬戶來驗證和執行 Safe 交易，而不是允許單個賬戶執行交易。 因此，即使攻擊者進入了一個賬戶，資金也無法轉移。 + +此外，建議選擇佔所有者 51%的閾值，例如 3 人中的 2 人、5 人中的 3 人等。 正因為如此，即使一位所有者失去了對其賬戶的訪問權限，用戶也不會立即被鎖定其在保險箱中的所有資金；相反，其他所有者仍可進行交易，例如，替換該丟失的所有者賬戶。 可以說，這是一種恢復機制。 + +**兼容哪些錢包？** +目前，Kaia Safe兼容[Kaia Wallet](https://docs.kaiawallet.io/)、[MetaMask](../../../tutorials/connecting-metamask.mdx)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md new file mode 100644 index 000000000000..37fabdf1ab10 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe-api-kit.md @@ -0,0 +1,270 @@ +--- +id: kaia-safe-api-kit +title: Kaia Safe API 工具包 +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Kaia Safe API 套件 + +API-Kit 是您與[安全交易 API](https://github.com/safe-global/safe-transaction-service)安全交互的必備工具包。 該工具包的核心功能是允許有效簽名者提出交易並與保險箱的其他簽名者共享交易，將簽名發送到服務機構以收集簽名，以及獲取保險箱的相關信息（如閱讀交易歷史、待處理交易、已啟用的模塊和守衛等）。 + +## 快速入門 + +在本指南結束時，您將能夠向服務部門提出交易建議，並獲得業主的簽名以執行交易。 + +## 先決條件 + +1. [Node.js和npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) +2. 有多個簽名人的保險箱 + +## 設置環境 + +### 步驟 1：創建項目目錄。 + +在終端中複製並粘貼此命令以創建項目文件夾。 + +```js +mkdir kaiasafe-api-kit +cd kaiasafe-api-kit +``` + +### 步驟 2：初始化 npm 項目。 + +在終端中複製並粘貼此命令，創建一個 `package.json` 文件。 + +```js +npm init -y +``` + +### 步驟 3：安裝依賴項。 + +使用 API-Kit 就像運行下面的安裝命令一樣簡單： + + + + ``` + npm install @safe-global/api-kit @safe-global/protocol-3 @safe-global/safe-core-sdk-types + ``` + + + + ``` + yarn add @safe-global/api-kit @safe-global/protocol-kit @safe-global/safe-core-sdk-types + ``` + + + +### 步驟 4：導入依賴項。 + +創建名為 `app.js` 的文件。 我們在此交互的所有代碼片段都將放在這裡。 + +將這些必要的導入複製並粘貼到 `app.js` 文件的頂部。 + +```js +import SafeApiKit from '@safe-global/api-kit' +import Safe from '@safe-global/protocol-kit' +import { + OperationType +} from '@safe-global/safe-core-sdk-types' +``` + +### 步驟 5：配置設置 + +為了有效說明 API-Kit 的工作原理，我們將使用一個有兩個或更多簽名者的 Safe 賬戶設置，閾值為兩個，因此在執行交易時需要收集多個簽名。 + +將以下內容複製並粘貼到 `app.js` 文件中的導入語句下： + +```js +// https://chainlist.org/?search=kaia&testnets=true +const RPC_URL = 'https://public-en-kairos.node.kaia.io' +const SAFE_ADDRESS = ""; // 2 Owner Safe Address Ex: 0x123.... SAFE SHOULD +const OWNER_1_ADDRESS = ""; // ONLY OWNER 1 and SAFE ADDRESS Need to have some test KAIA balance +const OWNER_1_PRIVATE_KEY = ""; +const OWNER_2_PRIVATE_KEY = ""; // OWNER 2 need not have any test KAIA +const TO_ADDRESS = OWNER_1_ADDRESS; // Receiver address of sample transaction who receives 1 wei +``` + +## 使用應用程序接口套件 + +### 步驟 1：初始化 API 工具包 + +要初始化 API 工具包，我們需要創建一個 API 工具包實例。 + +> 在支持 [Safe Transaction Service](https://docs.safe.global/core-api/transaction-service-overview) 的鏈中，只需指定 chainId 屬性即可。 + +```js +const apiKit = new SafeApiKit.default({ + chainId: 1001n, + txServiceUrl: 'https://docs-safe.kaia.io/txs-baobab/api' +}) + +``` + +如上所示，我們使用可選的 **txServiceUrl** 屬性加入了自定義服務。 + +### 步驟 2：初始化協議套件 + +為了處理交易和簽名，我們需要創建一個協議工具包實例（該工具包使開發人員能夠使用 TypeScript 接口與 [安全智能賬戶](https://github.com/safe-global/safe-smart-account) 進行交互），其中包含提供者、簽名者和 safeAddress。 + +```js +const protocolKitOwner1 = await Safe.default.init({ + provider: RPC_URL, + signer: OWNER_1_PRIVATE_KEY, + safeAddress: SAFE_ADDRESS +}) +``` + +### 步驟 3：向服務提出交易建議 + +API Kit 的核心功能之一是讓有效簽名者與其他簽名者共享交易。 但在此之前，任何一個安全簽名者都需要通過創建一個交易提案來啟動該過程。 然後，該交易將被髮送到服務程序，以便其他所有者也能訪問，從而獲得批准並簽署交易。 + +```js +const safeTransactionData = { + to: TO_ADDRESS, + value: '1', // 1 wei + data: '0x', + operation: OperationType.Call +} +const safeTransaction = await protocolKitOwner1.createTransaction({ + transactions: [safeTransactionData] +}) +const safeTxHash = await protocolKitOwner1.getTransactionHash(safeTransaction) +const signature = await protocolKitOwner1.signHash(safeTxHash) +// 2. Propose transaction to the service +try { + await apiKit.proposeTransaction({ + safeAddress: SAFE_ADDRESS, + safeTransactionData: safeTransaction.data, + safeTxHash, + senderAddress: OWNER_1_ADDRESS, + senderSignature: signature.data + }) +} catch(err) { + console.log(err) +} +``` + +### 步驟 4：檢索待處理交易 + +API 工具包根據不同情況為我們提供了不同的方法來檢索待處理交易。 在本指南中，我們將根據安全事務哈希值和下文註釋的其他可用方法來檢索事務： + +```js +const transaction = await apiKit.getTransaction(safeTxHash) +// const transactions = await service.getPendingTransactions() +// const transactions = await service.getIncomingTransactions() +// const transactions = await service.getMultisigTransactions() +// const transactions = await service.getModuleTransactions() +// const transactions = await service.getAllTransactions() +``` + +## 步驟 5：確認交易 + +接下來要做的是使用協議工具包簽署交易，並使用 [confirmTransaction](https://docs.safe.global/sdk/api-kit/reference#confirmtransaction) 方法將簽名提交給安全交易服務。 + +```js +const protocolKitOwner2 = await Safe.default.init({ + provider: RPC_URL, + signer: OWNER_2_PRIVATE_KEY, + safeAddress: SAFE_ADDRESS +}) +const signature2 = await protocolKitOwner2.signHash(safeTxHash) +// Confirm the Safe transaction +const signatureResponse = await apiKit.confirmTransaction( + safeTxHash, + signature2.data +) +``` + +### 步驟 6：執行交易 + +安全交易現在可以執行了。 可以使用[安全錢包 Web](https://app.safe.global/)界面、[協議工具包](https://docs.safe.global/sdk/protocol-kit#execute-the-transaction)、安全 CLI 或任何其他可用工具來完成。 + +最後一步，我們使用 Protocol Kit 執行安全交易。 + +```js +const safeTxn = await apiKit.getTransaction(safeTxHash); +const executeTxReponse = await protocolKitOwner1.executeTransaction(safeTxn) +const receipt = await executeTxReponse.transactionResponse?.wait(); +console.log('Transaction executed:'); +console.log(`https://kairos.kaiascan.io/tx/${hash}`) +``` + +最後，`app.js` 中的完整代碼應該是這樣的： + +```js +import SafeApiKit from '@safe-global/api-kit' +import Safe from '@safe-global/protocol-kit' +import { + OperationType +} from '@safe-global/safe-core-sdk-types' +// https://chainlist.org/?search=kaia&testnets=true +const RPC_URL = 'https://public-en-kairos.node.kaia.io' +const SAFE_ADDRESS = ""; // 2 Owner Safe Address Ex: 0x123.... SAFE SHOULD +const OWNER_1_ADDRESS = ""; // ONLY OWNER 1 and SAFE ADDRESS Need to have some test KAIA balance +const OWNER_1_PRIVATE_KEY = ""; +const OWNER_2_PRIVATE_KEY = ""; // OWNER 2 need not have any test KAIA +const TO_ADDRESS = OWNER_1_ADDRESS; // Receiver address of sample transaction who receives 1 wei +const apiKit = new SafeApiKit.default({ + chainId: 1001n, + txServiceUrl: 'https://docs-safe.kaia.io/txs-baobab/api' +}) +const protocolKitOwner1 = await Safe.default.init({ + provider: RPC_URL, + signer: OWNER_1_PRIVATE_KEY, + safeAddress: SAFE_ADDRESS +}) +// 1. Create transaction +const safeTransactionData = { + to: TO_ADDRESS, + value: '1', // 1 wei + data: '0x', + operation: OperationType.Call +} +const safeTransaction = await protocolKitOwner1.createTransaction({ + transactions: [safeTransactionData] +}) +const safeTxHash = await protocolKitOwner1.getTransactionHash(safeTransaction) +const signature = await protocolKitOwner1.signHash(safeTxHash) +// 2. Propose transaction to the service +try { + await apiKit.proposeTransaction({ + safeAddress: SAFE_ADDRESS, + safeTransactionData: safeTransaction.data, + safeTxHash, + senderAddress: OWNER_1_ADDRESS, + senderSignature: signature.data + }) +} catch(err) { + console.log(err) +} +console.log("Transaction hash is "+safeTxHash) +const transaction = await apiKit.getTransaction(safeTxHash) +// const transactions = await service.getPendingTransactions() +// const transactions = await service.getIncomingTransactions() +// const transactions = await service.getMultisigTransactions() +// const transactions = await service.getModuleTransactions() +// const transactions = await service.getAllTransactions() +// 3. Confirmation from Owner 2 +const protocolKitOwner2 = await Safe.default.init({ + provider: RPC_URL, + signer: OWNER_2_PRIVATE_KEY, + safeAddress: SAFE_ADDRESS +}) +const signature2 = await protocolKitOwner2.signHash(safeTxHash) +// Confirm the Safe transaction +const signatureResponse = await apiKit.confirmTransaction( + safeTxHash, + signature2.data +) +console.log(signatureResponse) +// 4. Execute transaction +const safeTxn = await apiKit.getTransaction(safeTxHash); +const executeTxReponse = await protocolKitOwner1.executeTransaction(safeTxn) +const receipt = await executeTxReponse.transactionResponse?.wait(); +console.log('Transaction executed:'); +console.log(`https://kairos.kaiascan.io/tx/${hash}`) +``` + +請訪問 [API 工具包參考](https://docs.safe.global/sdk/api-kit/reference) 瞭解更多信息，並訪問 [Github](https://github.com/kaiachain/kaia-dapp-mono/tree/main/examples/snippets) 訪問本指南的完整源代碼。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md new file mode 100644 index 000000000000..ccc9f3ecc997 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/kaia-safe.md @@ -0,0 +1,37 @@ +# Kaia Safe + +在 Kaia 這樣的典型區塊鏈平臺中，大多數用戶都熟悉單鍵錢包系統，如 Kaia Wallet 和 MetaMask，它們也被稱為外部擁有賬戶（EOA）。 這些賬戶使用傳統的密鑰對，即公共密鑰和私人密鑰，這並不理想，因為私人密鑰會造成單點故障。 + +這就使得 EOA 不適合組織使用，因為私鑰洩露可能導致組織損失全部加密貨幣資金--例如在 [Wintermute 黑客攻擊](https://www.certik.com/resources/blog/uGiY0j3hwOzQOMcDPGoz9-wintermute-hack-) 事件中，1.625 億美元的資金損失。 + +這就是 Kaia Safe 等多 ID 錢包的用武之地。 與單密鑰錢包不同，多簽名錢包需要多方的私鑰來簽署和執行交易，從而消除了單點故障，為組織用例提供了更高的安全性。 + +## 什麼是多重簽名錢包？ + +顧名思義，多重簽名錢包是一種需要兩個、三個或更多不同來源的私鑰來確認和執行加密交易的數字錢包。 + +例如，你可以把多重簽名錢包想象成一個有三把鎖的保險箱。 打開保險箱所需的三把鑰匙分別屬於三個不同的人，因此需要他們共同同意才能打開。 + +以下是多重簽名錢包的主要優點： + +- **安全存儲資產/資金：** 公司和協議可以安全地存儲資金，而不必擔心私鑰洩露或某個壞人未經授權轉移資金。 + +- \*\* 實現分散決策：\*\* 公司和企業高管可在鏈上決定執行哪些交易。 + +- **雙因素身份驗證：** 在多重簽名錢包的幫助下，企業和個人可以確保只有獲得必要密鑰的人才能執行交易。 + +接下來，我們將深入瞭解 Klatyn 的多 ID 錢包 Kaia Safe，以及如何使用它來管理您的資金和交易。 + +## Kaia Safe 是什麼？ + +Kaia Safe 是 Kaia 生態系統的多 ID 錢包。 它是著名的多重簽名錢包 [Gnosis Safe](https://gnosis-safe.io/) 的一個分叉。 + +## 益處 + +- **存儲和轉移 KAIA 和 KCT（KIP7、KIP17）**：用戶可以存入和轉移加密貨幣（KAIA）和代幣（可互換或不可互換）。 + +- **靈活性和安全性：** 確認閾值可讓用戶更靈活地控制應執行哪些交易，並消除單點故障。 + +- **安全應用程序：** Kaia Safe 的功能通過添加自定義應用程序得到擴展，這些應用程序可進行批量交易並與其他 dApps 進行交互。 這種安全應用程序的一個例子是**交易生成器**，它可以將多個交易合併為一個批量交易執行。 + +- **賬戶恢復：** 在丟失密鑰的情況下，只要剩餘密鑰仍能滿足確認閾值，Kaia Safe 賬戶就可以恢復。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md new file mode 100644 index 000000000000..3d3cf167bb8c --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/overview.md @@ -0,0 +1,15 @@ +# Kaia Safe 設計公司 + +目前，Kaia Safe 是一套用於創建和管理多重簽名錢包的工具，即 + +- **Safe React：** 這是一個用於創建多簽名錢包並與之交互的反應式網絡應用程序。 + +- **安全交易服務：** 跟蹤通過安全合約發送的交易，並監聽主網和 Kairos 中最近區塊的事件。 交易也可以發送到該服務，以便在鏈外收集簽名，或通知所有者即將發送到區塊鏈的交易。 + +- **安全配置服務：** 提供 Kaia Safe 客戶端環境的配置信息，例如所有鏈細節和應用程序接口的配置。 + +- **安全客戶端網關：** 這是 Kaia Safe 客戶端與後端服務（交易服務和 Kaia 節點）之間的網關。 + +- **安全基礎設施：** 這是一個集群設置，用於部署後端服務（安全交易、安全配置、安全客戶端網關）。 + +請參閱此 [鏈接](https://github.com/kaiachain/kaia-safe-infrastructure) 獲取更多信息。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md new file mode 100644 index 000000000000..83422057f6ea --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/tx-builder.md @@ -0,0 +1,77 @@ +# 使用事務生成器 + +這是 Kaia Safe 中的一個自定義應用程序，負責批處理交易。 這意味著您可以將幾筆交易捆綁在一起，而不必一筆接一筆地確認。 您只需確認並執行一次。 + +有了事務生成器，您就可以將從代幣轉賬到複雜的合約交互等各種事務組合在一起，並將它們批量合併到單個事務中。 + +## KAIA Token Transfer + +您可以按照以下步驟，使用事務生成器執行令牌轉移： + +**步驟 1：** 導航至安全應用程序並打開交易生成器安全應用程序 + +![](/img/build/tools/kaia-safe/ks-tx-builder.png) + +**第 2 步：** 輸入收件人錢包地址。 For this guide, kindly skip the ABI field as we are trying to execute KAIA transfer transaction. + +![](/img/build/tools/kaia-safe/tx-builder-token-recipient-addr.png) + +**Step 3:** Enter the KAIA value you want to send. + +> Note: In this guide, we are sending 1 KAIA, so we entered 1 in the **KAIA value** input field. You can input any amount here, depending on your Safe's KAIA balance. + +![](/img/build/tools/kaia-safe/tx-builder-token-trf-value.png) + +**步驟 4：** 點擊添加交易。 + +**步驟 5：** 對每個收件人地址重複步驟 2、3 和 4。 + +**步驟 6：** 將所有操作添加到批次後，單擊 "創建批次"。 + +![](/img/build/tools/kaia-safe/token-trf-tx-builder.gif) + +**第 7 步：** 審查並提交交易 + +您可以查看整個批次。 準備就緒後，單擊 "發送批次"，即可像其他安全交易一樣提交和執行交易。 + +## 合同互動 + +比方說，您想向一長串地址空投令牌，比如向 5 個地址空投 10 個 CCT 令牌。 交易生成器可將所有這些轉賬合併到一個交易中，而無需創建 5 個交易，保險箱的所有者必須一個接一個地確認和執行這些交易。 + +在本指南中，我們將 CCT 代幣鑄造到安全地址，以作說明。 + +讓我們使用事務生成器開始這個示例！ + +**步驟 1：** 打開安全應用程序。 + +![](/img/build/tools/kaia-safe/ks-tx-builder.png) + +**步驟 2：** 打開交易生成器安全應用程序 + +![](/img/build/tools/kaia-safe/ks-use-tx-builder.png) + +**第 3 步：** 輸入您的**令牌合同地址**和**ABI**。 + +在本例中，將使用 CCT 合同地址和 ABI。 您可以將 ABI 複製並粘貼到 **輸入 ABI** 字段中。 + +![](/img/build/tools/kaia-safe/kaia-safe-tx-builder-init.gif) + +**第 4 步：** 選擇一種方法並填寫交易信息 + +您可以從下拉菜單中選擇一種方法。 在這種情況下，我們選擇**轉移**方法。 要完成這一步，您必須填寫交易信息，如 **收件人（地址）** 和 **金額（uint256）**。 + +注：數值為無符號整數，不含小數。 在這個例子中，CCT 標記有 18 個小數。 因此，如果要發送 10 個 CCT，就必須輸入 10000000000000000000。 + +![](/img/build/tools/kaia-safe/kaia-safe-tx-builder-details.gif) + +**第 5 步：** 點擊**添加交易** + +**步驟 6：** 對每個收件人地址重複步驟 **4**、**5** 和 **6**。 + +**第 7 步：** 將所有操作添加到批次後，單擊**創建批次**。 + +![](/img/build/tools/kaia-safe/kaia-safe-tx-builder-batch.gif) + +**第 8 步：** 審查並提交交易 + +您可以查看整個批次。 準備就緒後，點擊**發送批次**，即可像其他安全交易一樣提交和執行交易。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md new file mode 100644 index 000000000000..63ef2858e715 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-safe/use-kaia-safe.md @@ -0,0 +1,169 @@ +# 使用 Kaia Safe + +## 創建安全 + +在這裡，您將瞭解到如何在 Kaia 網絡上創建 Safe 並評估其益處。 + +**步驟 1：** 導航至 [Kaia Safe App](https://safe.kaia.io/)。 通過在網絡瀏覽器上導航到應用程序，您可以探索 Kaia Safe 的功能。 + +**步驟 2：** 連接 [錢包](https://docs.ethhub.io/using-ethereum/wallets/intro-to-ethereum-wallets/)。 目前，Kaia Safe 支持多種錢包，如 [Kaia Wallet](https://docs.kaiawallet.io/)、[MetaMask](../../../tutorials/connecting-metamask.mdx) 錢包等。 + +在本指南中，我們將使用 MetaMask。 確保您的 MetaMask 錢包已添加 Kaia 網絡（[Mainnet](../../../tutorials/connecting-metamask.mdx#connect-to-kaia-network)或 [Kairos Testnet](../../../tutorials/connecting-metamask.mdx#connect-to-kaia-network))，以便成功連接。 + +![](/img/build/tools/kaia-safe/kaia-safe-connect-wallet.png) + +**第 3 步：** 連接錢包後，點擊**創建賬戶**，併為新保險箱命名。 這個名字與您的安全賬戶相連，安全賬戶是一個多簽名錢包，可以保存和存儲您的所有資金。 + +**第 4 步：** 輸入有權提交和批准交易的地址，添加所有者/簽名者。 您可以添加任意數量的簽名者，也可以隨時刪除或替換任何簽名者。 + +**第 5 步：** 選擇安全賬戶交易需要多少次簽名確認才能獲得批准。 需要注意的是，我們的應用程序默認情況下只允許一個簽名者確認。 但建議使用大於 1 的閾值，以確保賬戶安全可靠。 良好的做法是以業主總數的 51% 為界限，例如三分之二、五分之三等，如下圖所示： + +![](/img/build/tools/kaia-safe/kaia-safe-create-acct.gif) + +**第 6 步：** 審查並部署安全系統 + +一旦您對 Safe 的所有參數完全滿意，您就可以提交創建 Safe 賬戶，並按照屏幕上的說明完成賬戶創建。 + +![](/img/build/tools/kaia-safe/kaia-safe-create-review.gif) + +恭喜您成功創建 Kaia Safe 賬戶！ + +## 增加資產 + +在本節中，您將瞭解如何將資產（KAIA、FT、NFT）添加到安全賬戶並確保資金安全。 + +### KAIA 存款 + +以下是將 **KAIA** 添加到您的安全賬戶的步驟 + +**步驟 1：** 從賬戶控制面板複製您的安全地址。 + +![](/img/build/tools/kaia-safe/ks-deposit-copy-addr.png) + +**步驟 2：** 打開 Metamask 錢包，點擊**發送**，將資產發送到您的安全賬戶。 + +請注意，將資產發送到 Safe 賬戶有不同的方法。 您可以通過 [硬件錢包](https://www.ledger.com/academy/crypto-hardware-wallet)、[網絡錢包](https://medium.com/arcana-network-blog/why-web-wallets-e77c776e4d5e) 甚至智能合約發送。 在本例中，我們使用的是名為 MetaMask 的網絡錢包。 + +![](/img/build/tools/kaia-safe/ks-token-send-btn.png) + +**第 3 步：** 在搜索欄中輸入您的安全地址，如下所示。 + +**步驟 4：** 輸入**金額**，然後點擊**下一步**。 + +![](/img/build/tools/kaia-safe/ks-token-send-details.png) + +**第 5 步：** 確認交易並查看資產儀錶板。 您可以看到從 metamask 賬戶轉入 Kaia Safe 賬戶的金額。 + +![](/img/build/tools/kaia-safe/kaia-safe-klay-bal.png) + +### KIP-7 存款 + +現在，我們來看看如何通過以下步驟將 KIP7（可替代代幣）存入我們的保險箱。 + +**步驟 1：** 從賬戶控制面板複製您的安全地址。 + +![](/img/build/tools/kaia-safe/ks-deposit-ft-copy.png) + +**步驟 2：** 打開 Metamask 錢包，導航至**資產**選項卡。 + +**第 3 步：** 選擇您喜歡發送的令牌，然後點擊**發送**。 + +![](/img/build/tools/kaia-safe/ks-ft-send-btn.png) + +**步驟 4：** 重複上述**KAIA**存款的步驟**3**、**4**、**5**。 + +![](/img/build/tools/kaia-safe/ks-ft-send-details.png) + +**第 5 步：** 查看您的資產儀錶板，您可以看到 KIP7 代幣正在轉入您的安全賬戶。 同樣，您也可以將任何 Fungible 代幣轉入您的安全賬戶。 + +![](/img/build/tools/kaia-safe/ks-ft-balance.png) + +### KIP-17 (NFTs) 存款 + +現在，我們來看看如何按照以下步驟將 KIP17（不可兌換代幣）存入我們的保險箱。 + +您可以通過多種方式將 NFT 轉入您的安全賬戶。 下面是一個如何使用 [OpenSea](https://opensea.io/about) 將 NFT 轉入安全賬戶的示例。 + +1. 導航至您的 [OpenSea 帳戶](https://testnets.opensea.io/account) 資料頁面 +2. 導航至您喜歡轉接的 NFT。 確保選擇 Kaia 網絡（主網或 Kairos）上的 NFT +3. 在下一頁，點擊傳輸按鈕。 +4. 將保險箱地址粘貼到文本框中，然後傳輸到保險箱 +5. 在 Kaia Safe 的 "資產 "部分，您可以找到 OpenSea 的 NFT。 + +![](/img/build/tools/kaia-safe/kaia-safe-trf-nft.gif) + +有關轉移 NFT 的更多詳情，請參閱 OpenSea 提供的 [指南](https://support.opensea.io/en/articles/8866959-how-can-i-transfer-an-nft-using-opensea)。 + +## 發送資產 + +在本節中，您將學習如何從 Kaia Safe 賬戶發送 KAIA 和 KIP-7 令牌。 + +### 發送 KAIA 和 KIP7 令牌 + +**步驟 1：** 點擊側邊菜單中的**新交易**按鈕，選擇**發送代幣**，開始新的資產轉移。 + +![](/img/build/tools/kaia-safe/kaia-safe-init-send-token.gif) + +**第 2 步：** 選擇要轉移的資產。 + +- **KAIA** + +> 注：添加**收件人地址**和 KAIA 的**金額**，以發送轉賬 KAIA。 + +![](/img/build/tools/kaia-safe/kaia-safe-send-token-details.gif) + +- **KIP-7令牌** + +在資產下拉菜單中選擇要發送的代幣，如上圖所示。 + +> 注意：添加收件人地址和代幣數量，以傳輸 KIP7 代幣。 + +**第 3 步：** 審查並提交交易。 您需要用簽名者錢包簽署交易，一旦達到確認閾值，交易就會執行。 + +![](/img/build/tools/kaia-safe/kaia-safe-review-send-tokens.gif) + +### 發送 NFT + +在本節中，您將學習如何從 Kaia Safe 賬戶發送不可兌換的代幣。 + +**步驟 1：** 單擊側菜單中的**新交易**按鈕，選擇**發送 NFT**，開始新的資產轉賬。 + +![](/img/build/tools/kaia-safe/kaia-safe-init-send-nft.gif) + +**第 2 步：** 選擇要轉移的資產。 + +![](/img/build/tools/kaia-safe/kaia-safe-send-nft-details.gif) + +**第 3 步：** 審查並提交交易。 您需要用簽名者錢包簽署交易，一旦達到確認閾值，交易就會執行。 + +![](/img/build/tools/kaia-safe/kaia-safe-review-send-nft.gif) + +## 其他說明 + +在使用 Kaia Safe 時，您需要注意以下事項： + +### 交易費用 + +Kaia Safe 交易，無論是資產轉移還是合同互動，都會產生一筆費用，這筆費用將由執行交易的簽名者（通常是達到所需簽名門檻的最後一個簽名者）支付。 + +### 安全 Nonce + +出於安全考慮，使用 Safe 進行的交易必須按順序執行。 為此，我們為事務分配了一個名為 "**nonce**"的數字，以確保每個事務只能執行一次。 + +![](/img/build/tools/kaia-safe/ks-nounce.png) + +在任何給定的時間內，只能執行nonce為_上一次執行的事務+1_的事務。 非ce 值較高的事務將排隊等待執行。 因此，每當一個事務完成後，只要隊列中的下一個事務積累了足夠的簽名，就可以執行。 + +![](/img/build/tools/kaia-safe/ks-pending-tx.png) + +### 特定連鎖店地址 + +您可以選擇複製帶鏈前綴的地址 + +- 複製帶鏈前綴的地址： + +![](/img/build/tools/kaia-safe/ks-chain-spec-addr.png) + +從儀錶板複製安全地址粘貼到錢包時，如上圖所示，您可以點擊複選框選擇是否添加鏈名。 建議您不要選中它，以避免出現以下錯誤。 + +![](/img/build/tools/kaia-safe/ks-chain-addr-err.png) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md new file mode 100644 index 000000000000..7f0c91ae062c --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/kaia-wallet.md @@ -0,0 +1,33 @@ +# Kaia 錢包 + +![](/img/banners/kaia-kaiawallet.png) + +Kaia 錢包是 Kaia 網絡的瀏覽器擴展錢包。 Kaia 錢包可在 Google Chrome 瀏覽器中使用，它提供了一種通過網絡瀏覽器與 Kaia 網絡進行交互的安全、可用的方式。 使用 Kaia 錢包，您可以存儲您的 KAIA 和基於 Kaia 的代幣並進行交易。 您還可以在 +即時簽署來自基於網絡的 dApps（去中心化應用程序）的請求。 + +- 從 Chrome 網上商店下載：[link](https://chromewebstore.google.com/detail/kaia-wallet/jblndlipeogpafnldhgmapagcccfchpi) + +開發人員請訪問 [https://docs.kaiawallet.io](https://docs.kaiawallet.io)，瞭解如何使用 Kaia 錢包開發 dApp。 + +## 基於 PC 網絡瀏覽器的分散式高清錢包 + +Kaia Wallet 是 Chrome 瀏覽器的一個網絡擴展。 Kaia Wallet 針對桌面環境進行了優化。 + +Kaia 錢包提供用戶賬戶和密鑰的可管理性。 所有交易都透明地記錄在 Kaia 區塊鏈上，因此任何人都可以使用 [Kaiascope] 訪問交易歷史。 + +Kaia 錢包是一種分層確定性（HD）錢包，這意味著它能從單個種子短語無限生成分層樹狀結構的私鑰/公鑰。 種子短語由記憶代碼詞組成，因此比由隨機字母數字組成的短語更容易記憶。 用戶的私人密鑰經過加密並存儲在瀏覽器中。 + +通過上述功能，Kaia 錢包改善了當前區塊鏈體驗的安全性、透明度和用戶友好性。 不過，用戶必須負責管理自己的個人賬戶。 例如，如果用戶不記得他/她的種子短語，就沒有其他辦法恢復他/她的賬戶。 + +## 支持各種 Kaia 網絡和代幣 + +Kaia 錢包允許您存儲和交易所有基於 Kaia 的代幣，包括 KAIA。 默認情況下未加載的令牌可以通過粘貼其合約地址來插入。 您甚至可以在 Kaia 錢包上存儲和交易您自己的基於 Kaia 的自定義代幣！ + +Kaia 錢包支持 Kaia 的 Kairos 測試網和主網。 此外，Kaia 錢包還支持基於 Kaia 的 dApp 開發人員的私有鏈，這些開發人員可能希望在其私有網絡中流通定製代幣。 + +## 簽署基於網絡的 dApp 交易 + +Kaia Wallet 在您和 dApp 之間架起了一座橋樑，使您能夠使用 Kaia Wallet 賬戶簽署從 dApp 流向您的交易/數據。 +Kaia 錢包也是開發人員處理[費用委託交易](../../../learn/transactions/transactions.md#fee-delegation)的輔助工具。 使用 Kaia 錢包，交易發送方和費用支付方都能迅速簽署費用委託交易。 + +[Kaiascope]: ../block-explorers/kaiascope.md diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md new file mode 100644 index 000000000000..a7bea487b28f --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/particle.md @@ -0,0 +1,331 @@ +--- +sidebar_label: Particle Network +--- + +# 將粒子網絡整合到 dApp 中 + +![](/img/banners/kaia-particle.png) + +## 導言 + +[粒子網絡](https://particle.network) 提供錢包抽象服務，以簡化用戶入門。 + +[粒子連接 SDK](https://developers.particle.network/api-reference/connect/desktop/web) 支持與 EVM 兼容的鏈，包括 Kaia 及其測試網。 它允許使用[社交和 Web3 登錄選項](https://developers.particle.network/api-reference/connect/desktop/web#wallet-connectors)進行 2 鍵登錄，所有操作都在一個模態中完成。 + +通過 Particle Network，Kaia 開發人員可以為 Kaia 主網和測試網嵌入社交登錄，讓用戶只需使用他們的谷歌、電子郵件、X 等信息就能在您的應用程序中生成和使用錢包。 + +本頁提供在基於 Kaia 的應用程序中實施 Particle Connect 的概述和教程，以幫助您開始集成過程。 + +## 先決條件 + +- 使用 TypeScript 和 Tailwind CSS 設置的 [Next.js 項目](https://nextjs.org/docs/getting-started/installation) + - 您可以運行： `npx create-next-app@latest` 來創建它。 +- 來自 [Particle Dashboard](https://dashboard.particle.network)的**項目 ID**、**客戶密鑰**和**應用程序 ID**。 + +## 安裝 + +要在您的 dApp 中利用 Particle Network，特別是 Particle Connect，您首先需要安裝所需的庫。 Particle Connect SDK 通過一個界面簡化了錢包創建、用戶登錄和區塊鏈交互過程。 它支持社交登錄和 Web3 登錄，便於訪問。 + +要安裝 SDK 以及 Viem（連接後臺）和 ethers（演示 EIP-1193 提供商），請運行 + +```shell +yarn add @particle-network/connectkit viem@^2 ethers +``` + +## 初始化粒子連接 + +首先，我們將設置 Particle Connect，這是 Particle 的旗艦認證 SDK。 在項目根目錄下創建名為 `ConnectKit.tsx` 的新文件。 該文件將容納 "ParticleConnectKit "組件，它是已配置的 "ConnectKitProvider "實例的包裝器，是配置 Particle Connect 的主要接口（我們稍後將以編程方式介紹）。 + +接下來，前往 [Particle dashboard](https://dashboard.particle.network)，創建一個新的網絡應用程序項目，並獲取以下必要的 API 密鑰： + +- **`projectId`** - 項目的唯一標識符。 +- **`clientKey`** - 客戶端特有的密鑰。 +- **`appId`** - 應用程序的 ID。 + +將這些 API 密鑰存儲在`.env`文件中，如下所示： + +```plaintext +next_public_project_id='project_id' +next_public_client_key='client_key' +next_public_app_id='app_id' +``` + +現在，將以下代碼添加到您的 `ConnectKit.tsx` 文件中： + +```js +"use client"; + +import React from "react"; +import { ConnectKitProvider, createConfig } from "@particle-network/connectkit"; +import { authWalletConnectors } from "@particle-network/connectkit/auth"; +import { defineChain } from "@particle-network/connectkit/chains"; +import { wallet, EntryPosition } from "@particle-network/connectkit/wallet"; + +const kaiaMainnet = defineChain({ + id: 8217, + name: "Kaia", + nativeCurrency: { + decimals: 18, + name: "KAIA", + symbol: "KAIA", + }, + rpcUrls: { + default: { + http: ["https://public-en.node.kaia.io"], + }, + }, + blockExplorers: { + default: { name: "Explorer", url: "https://kaiascope.com/" }, + }, + testnet: false, +}); + +const kaiaTestnet = defineChain({ + id: 1001, + name: "Kaia Testnet", + nativeCurrency: { + decimals: 18, + name: "KAIA", + symbol: "KAIA", + }, + rpcUrls: { + default: { + http: ["https://public-en-kairos.node.kaia.io"], + }, + }, + blockExplorers: { + default: { name: "Explorer", url: "https://kairos.kaiascope.com/" }, + }, + testnet: true, +}); + +const config = createConfig({ + projectId: process.env.NEXT_PUBLIC_PROJECT_ID!, + clientKey: process.env.NEXT_PUBLIC_CLIENT_KEY!, + appId: process.env.NEXT_PUBLIC_APP_ID!, + + walletConnectors: [authWalletConnectors({})], + + plugins: [ + wallet({ + entryPosition: EntryPosition.BR, // Positions the modal button at the bottom right on login + visible: true, // Determines if the wallet modal is displayed + }), + ], + chains: [kaiaMainnet, kaiaTestnet], +}); + +export const ParticleConnectkit = ({ children }: React.PropsWithChildren) => { + return {children}; +}; +``` + +該組件的幾乎所有屬性都可以配置，從支持的不同登錄類型到模態的視覺外觀；要探索這些不同的選項，請訪問 [Particle 文檔](https://developers.particle.network/api-reference/connect/desktop/web#configuration)。 + +## 將 Particle Connect 集成到您的應用程序中 + +配置完成後，用 "ParticleConnectKit "組件封裝您的應用程序，以啟用對 Particle Connect SDK 的全局訪問。 要做到這一點，請對 `src` 目錄中的 `layout.tsx` 文件作如下修改： + +```typescript +import { ParticleConnectkit } from '@/connectkit'; +import type { Metadata } from 'next'; +import { Inter } from 'next/font/google'; +import './globals.css'; + +const inter = Inter({ subsets: ['latin'] }); + +export const metadata: Metadata = { + title: 'Particle Connectkit App', + description: 'Generated by create next app', +}; + +export default function RootLayout({ + children, +}: { + children: React.ReactNode; +}) { + return ( + + + {children} + + + ); +} +``` + +### 連接錢包 + +設置好 "layout.tsx "文件後，就可以通過中央**連接錢包**按鈕連接用戶了。 您可以從 `@particle-network/connectkit` 中導入 `ConnectButton` 來實現這一功能。 一旦用戶登錄，"連接按鈕 "就會變成一個嵌入式部件。 + +```js +import { ConnectButton, useAccount } from '@particle-network/connectkit'; + +export const App = () => { + const { address, isConnected, chainId } = useAccount(); + + // Standard ConnectButton utilization + return ( +
+ + {isConnected && ( + <> +

Address: {address}

+

Chain ID: {chainId}

+ + )} +
+ ); +}; +``` + +### 獲取賬戶和餘額 + +通過 `ConnectButton` 組件成功連接錢包（或社交登錄）後，就可以檢索用戶的相關 Kaia 地址。 此外，您還可以通過 "publicClient"（利用 Particle Connect 已設置的 Viem 提供商）檢索其當前餘額（以 KAIA 為單位）。 + +```js +"use client"; + +import { useState, useEffect } from "react"; +import { + ConnectButton, + useAccount, + usePublicClient, +} from "@particle-network/connectkit"; +import { formatEther } from "viem"; + +export default function Home() { + // Account-related states + const { isConnected, address, chain } = useAccount(); + const publicClient = usePublicClient(); + + // State variable for balance + const [balance, setBalance] = useState(""); + + // Fetch and display user balance when connected + useEffect(() => { + const fetchBalance = async () => { + if (address) { + try { + const balanceResponse = await publicClient.getBalance({ address }); + const balanceInEther = formatEther(balanceResponse); + setBalance(balanceInEther); + } catch (error) { + console.error("Error fetching balance:", error); + } + } + }; + + if (isConnected) { + fetchBalance(); + } + }, [isConnected, address, publicClient]); + + return ( +
+ + {isConnected && ( +
+

Account Details

+

+ Address: {address || "Loading..."} +

+

+ Balance: {balance || "Loading..."} {chain?.nativeCurrency.symbol} +

+
+ )} +
+ ); +} +``` + +### 斷開錢包連接 + +用戶登錄後，可以通過源自 `useDisconnect` 的 `disconnect` 以編程方式強制註銷。 這將斷開當前活動會話與 dApp 的連接，使用戶返回初始狀態。 + +```js +import { useDisconnect } from "@particle-network/connectkit"; + +const { disconnect } = useDisconnect(); + +// Inside your component's JSX + + +``` + +### 獲取用戶信息 + +當用戶通過社交賬戶連接時，可以使用 `useParticleAuth()` 鉤子訪問 `userinfo`，其中包括用戶的連接方式、賬戶創建日期、姓名、電子郵件和其他[來自 Particle Auth 的相關信息](https://developers.particle.network/api-reference/connect/desktop/web#fetch-user-information-with-particle-auth)。 + +```js +import { useAccount, useParticleAuth, useWallets } from '@particle-network/connectkit'; +import { useState, useEffect } from 'react'; + +export const App = () => { + const { getUserInfo } = useParticleAuth(); + const { isConnected } = useAccount(); + + // Retrieve the primary wallet from the Particle Wallets + const [primaryWallet] = useWallets(); + + // Store userInfo in a useState to use it in your app + const [userInfo, setUserInfo] = useState(null); + + useEffect(() => { + const fetchUserInfo = async () => { + // Use walletConnectorType as a condition to avoid account not initialized errors + if (primaryWallet?.connector?.walletConnectorType === 'particleAuth') { + const userInfo = await getUserInfo(); + setUserInfo(userInfo); + } + }; + + fetchUserInfo(); + }, [isConnected, getUserInfo]); + + return

Name: {userInfo.name || 'N/A'}

; +}; +``` + +### 發送本地事務 + +Particle Connect 允許您利用現有的 EIP-1193 提供商，在本例中，我們創建了一個帶有 `ethers` 的提供商實例來發送轉賬交易。 + +```js +import { useWallets } from "@particle-network/connectkit"; +import { ethers, type Eip1193Provider } from "ethers"; + +const [primaryWallet] = useWallets(); + +const executeTransaction = async () => { + // Get the provider from the primary wallet's connector + const EOAprovider = await primaryWallet.connector.getProvider(); + + // Initialize a custom provider using ethers.js with the obtained EIP-1193 provider + const customProvider = new ethers.BrowserProvider(EOAprovider as Eip1193Provider, "any"); + + // Get the signer (an abstraction of the account that can sign transactions) + const signer = await customProvider.getSigner(); + + // Send a transaction with specified recipient address, amount (0.01 ETH), and empty data + await signer.sendTransaction({ + to: recipientAddress, + value: parseEther("0.01"), + data: "0x", + }); +}; + + +``` + +## 下一步工作 + +您可以在 [Particle Connect 文檔](https://developers.particle.network/api-reference/connect/desktop/web#key-react-hooks-for-particle-connect) 中找到可用鉤子的完整列表。 + +有關 Particle Network（Particle Connect、Particle Auth 和其他 SDK）的其他指南，請參閱 [Particle Network 文檔](https://developers.particle.network) 和 [Particle Network GitHub 賬戶](https://github.com/Particle-Network)。 此外，您還可以訪問 [Particle Network 博客](https://blog.particle.network) 瞭解有關 Particle Network 服務、即將發佈的版本和技術棧的更多信息。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md new file mode 100644 index 000000000000..53ac8995c507 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/build/tools/wallets/wallet-libraries/privy.md @@ -0,0 +1,452 @@ +--- +sidebar_label: Privy +--- + +# 將 Privy 整合到 dApp 中 + +![](/img/banners/kaia-privy.png) + +## 導言 + +[Privy](https://docs.privy.io/)是一個簡單的錢包工具包，用於在 web3 中進行漸進式身份驗證。 有了 Privy，開發人員可以使用傳統和 web3 身份驗證方法登錄用戶，實現漸進式登錄，提高用戶轉化率。 + +在本指南中，您將使用 Privy 錢包工具包將 Metamask、Coinbase Wallet 等外部錢包以及 Google、Twitter、Email 等社交登錄信息整合到您在 Kaia 網絡上構建的 dApp 中。 + +## 先決條件 + +- 一個正在運行的 Next.js 項目。 您可以克隆 Privy 提供的 [create-next-app](https://github.com/privy-io/create-next-app) 模板來學習本教程。 +- 來自[Privy 開發者控制檯](https://console.privy.io/)的[應用程序ID](https://docs.privy.io/guide/console/api-keys#app-id) + +## 開始 + +克隆模板是一個簡單的 Next.js Privy Auth 入門模板，包含三個主要核心文件： + +- **index.tsx**：該文件處理用戶的登錄驗證。 +- **app.tsx**：該文件處理 Privy SDK 的初始化，並用 PrivyProvider 封裝我們的組件。 +- **dashboard.tsx**：這是用戶登錄後重定向到的頁面。 它可以測試每種登錄方法（谷歌、Twitter、電子郵件、錢包）。 對於本指南來說，更重要的是，我們將在使用 MetaMask 等外部錢包連接時執行某些功能。 這些功能包括：獲取用戶餘額、向另一個賬戶發送 KAIA、部署合約、與智能合約交互。 + +## 安裝 + +要在 dApp 中使用 Privy，必須先安裝所需的庫和 SDK。 因此，您需要設置 ethers.js，以及 [Privy React Auth SDK](https://www.npmjs.com/package/@privy-io/react-auth)。 您可以將 Privy 與 [etherthers.js](https://docs.ethers.org/v6/)、[web3.js](https://web3js.readthedocs.io/en/v1.2.8/getting-started.html)、[viem](https://viem.sh/) 庫一起使用，與 Kaia 區塊鏈進行通信。 在本指南中，我們將使用 ethers.js 庫。 + +打開項目文件夾，運行下面的命令安裝所需的庫和 SDK： + +```bash +npm install —save @privy-io/react-auth +npm install --save ethers +``` + +## 初始化特權和特權提供程序 + +成功安裝所需的庫後，接下來就是用[PrivyProvider](https://docs.privy.io/reference/react-auth/modules#privyprovider)來封裝組件。 + +PrivyProvider 應封裝任何將使用 Privy SDK 的組件。 為此，請打開 _app.tsx 文件並粘貼下面的代碼： + +```tsx +import '../styles/globals.css'; +import type {AppProps} from 'next/app'; +import Head from 'next/head'; +import {PrivyProvider} from '@privy-io/react-auth'; +import {useRouter} from 'next/router'; +function MyApp({Component, pageProps}: AppProps) { + const router = useRouter(); + return ( + <> + + Privy Auth Starter + + + router.push('/dashboard')} + > + + + + ); +} +export default MyApp; +``` + +值得注意的是，特權提供者具有以下屬性： + +- 您的 `appID` 需要在 .env 文件中更新。 您可以使用 Privy 為測試目的提供的以下 "測試應用程序 ID：clpispdty00ycl80fpueukbhl "開始使用。 +- 一個可選的 `onSuccess` 回調，用戶成功登錄後執行該回調。 +- 一個可選的 "createPrivyWalletOnLogin "布爾值，用於配置是否希望用戶在登錄時創建嵌入式錢包。 +- 可選配置屬性，用於自定義上機體驗。 + +## 連接錢包 + +在 `index.tsx` 文件的 LoginPage 函數中，調用 [login](https://docs.privy.io/reference/react-auth/interfaces/PrivyInterface#login) 方法，打開 Privy 登錄模態，提示用戶登錄。 + +```ts + import {usePrivy} from '@privy-io/react-auth'; + + + const {login} = usePrivy(); + return ( +
+ +
+ ); +``` + +![](/img/build/tools/privy-connect-banner.png) + +## 獲取賬戶和餘額 + +通過上面的步驟，你會發現我們是通過連接錢包登錄的。 在這一步中，我們將檢索用戶的相關 Kaia 地址。 此外，您還可以使用 ethers.js 檢索其當前餘額（以 KAIA 為單位）。 + +在 dashboard.tsx 文件中，粘貼以下代碼： + +```tsx +import {useRouter} from 'next/router'; +import React, {useEffect, useState} from 'react'; +import {usePrivy, useWallets} from '@privy-io/react-auth'; +const {ready, authenticated} = usePrivy(); +const {wallets} = useWallets(); + +useEffect(() => { + if (ready && !authenticated) { + router.push('/'); + } + }, [ready, authenticated, router]); + +const [balance, setBalance] = useState(""); +async function getBalance() { + if (!authenticated) { + console.log("user not authenticated yet"); + return; + } + const provider = await wallets[0].getEthersProvider(); + const signer = provider.getSigner(); + // Get user's Ethereum public address + const address = await signer.getAddress(); + console.log(address); + + // Get user's balance in ether + const balance = ethers.formatEther( + (await provider.getBalance(address)).toString() // balance is in wei + ); + console.log(balance); + setBalance(balance); +} + +return ( + {ready && authenticated ? ( +
+ +

{balance ? ` User with ${wallets[0].address} has ${balance} KAIA` : "None"}

+
+) : null } +); +``` + +## 斷開錢包連接 + +斷開錢包 +用戶登錄後，可以通過從 usePrivy 派生的 `logout` 方法以編程方式註銷用戶。 這將斷開當前活動會話與 dApp 的連接，使用戶返回初始狀態。 + +```tsx +const { logout } = usePrivy(); + + +return ( + {ready && authenticated ? ( +
+ +
+) : null } + ); +``` + +## 獲取用戶信息 + +Privy 為用戶提供了使用 web3 錢包和社交登錄連接到 dApp 的便利。 如果用戶使用自己的社交賬戶（如 twitter、discord、谷歌賬戶等）連接到 dApp，您就可以從 `usePrivy` 中調用 `user`，這會返回一個包含用戶 ID、電子郵件、錢包地址等關鍵信息的對象。 + +```tsx +const { user } = usePrivy(); + +return ( + {ready && authenticated ? ( +
+
+

User object

+