tktechblogスマートフォン用の表示で見るtktechblog日々の記録用です。blockchain,bitcoin,ethereumメインです。この広告は、90日以上更新していないブログに表示しています。deeds.abstractNFTsのためのapi実行を許可する基本方針をまとめたもの。application任意の量のNFTsを発行することを可能にする。この企画はeip20にインスパイヤされて立てられたものであるが、eip20ではNFTsのトラッキング機能が不足したいた。トークンで扱う量はidentical(特定可能)/fungibleな性質を持つ。2119.結構要件が指定されてる。assetsに依存したスマートコントラクトは多くのユースケースが提案されている。Propy.nftのネーミングを考えてる時に他の候補にあったもの。ethereum上記三社の投資先、買収先を調べてみた。今までの事業内容と合わせて、今後のコングロマリット化を想像してみると参考になった。bitmainの場合は、手元キャッシュがどうなるのかわからない、ハードの赤字額が膨らんでいてIPOに対してどのような影響があるのかなども考えてみようと思う。ブロックチェーンのレイヤーを大きく分けて行くと、今後自分の身のおく場所はどのレイヤーにするのかと考える必要があるなと思った。user/developer/minerの調和のなかで初めて価値を有するblockchainと言う技術であることを考えると、どの立場に立って、どのようなビジョン、未来像を持って、開発を進めて行くのかと言うことはかなり重要。最近は開発とリサーチどちらもやっているし、国内、国外、ビジネス面、開発者コミュニティの中での分布図をなんとなく把握できたので、どのベクトルに向けてみんなが動いているのかと言うことも大方理解できてきた。最近はethereum/bitcoin以外にも新しいネットワークも立ち上がってきた。自分の仮説が正しいのか、解像度を高めて行くために引き続き、リサーチと開発をすすめていき、早めに長期的な道筋を定めて、素早く打ち手をとって行きたい。callしてwebとcontractを繋げる実装を行なった。詳しく調べていきたい。baseのdappsを作ってみようと試みたが、良くわからないバグと遭遇するためにreactを基本に実装予定。ethereumtruffleやnpmいじってるとたまに出てくるこのエラーに関して良い解説が見つからなかったけど、中国のソース掘ったら良いものがあって、解決できた。デバッグ時に英語だけでなく中国ソースも掘っていこうと感じた。dev無駄に使ってるプロセスは切る。guiでなくちゃならないものでなければ、処理が重くなるだけなのでcliで起動させるnode_moduleは詳しく見とくpackage.jsonは詳しく見とくクライアント、サーバー、コントラクトはそれぞれ設計をきちんと考える。良い仕組みがあればモジュール化して再利用できるように自分で作っておく。環境構築は再現性を持たせるために、ドキュメントかdotfilesに残す。開発で学んだこと、できなかったことはブログに残して、振り返って次に活かす。resolutionsの時のトークンの扱いの基準。tokens.erc20やerc791のようなトークンのapi実行を許可する基準。motivation強盗にあってトークンやアセットの無くなったり盗まれたりした際に影響を和らげたり、他の紛争の手助けになるようにすること。ethereumプロトコルは無くなったり、盗まれたり、紛争によって修正されるべきではない。standardは安全性の構成可能性の提供によって、ユーザーやコントラクトの安全性の要求に答えるこのstandardの実行は、ユーザーにオプトインベースでユーザーに論争解決の選択肢として提供することができるし、コミュニティにとっても、補填行動に意識をおく負担が減る。ETH.erc20トークンやethにcontractやinterfaceに解決不能なissueを記入し、報酬と合わせて支払いを行う仕組みの提案。bountyとともに開発スピードが高まって行ったが、イーサリアムにもあった方が開発が早く進むと考える。issuer.フローとコードベースの仕様がEIP状に載っている。methodの詳細に関しての提案。eth_sendTransaction)。その代わりにユーザーにhtmlのポップアップを使って、トランザクションの商品を得るという仕様に関しての提案。apiにアクセスすることができない。domainではdappsは動かない。transactionが可能になる。settingを変える必要があるだけでなく、それを使うためにユーザーはそのdappsをtrustすることを強制させる。これは受け入れがたいことだし、既存のdappsの立場上よくない。interfaceを経由して、トランザクションをするかどうか尋ねられるみたいな面倒なケースも考えられる。friendlyを提供することが狙い。いくつかのscreenshotを元に実装例を提案。securityのために提案。oauth-likeなプロトコルも検討したが、実装が大変だし、gethの仕様と合わせて話し合う必要がある。そのため、iframe/windowの方が、組み込みが容易だと判断し、こちらを提案。Blockchain.userが実行許可にサインすることはある。relayerがそれらを実行するために扱われるパターンもある。developerに多くのflexibilityを与えて、アプリケーションをuserとblockchainの連携をすることに集中させたい。pointsの多くが解決されます。message以下の順番で連結されないといけない。contractsおそらく結構重い提案というか、初期から肉付けされて巨大化したeipっぽい。他の関連部分も読み返しながら、あとで振り返って改めて読み返そうと思う。typeも必要なしにする提案。transactionに関して言えば新しく考える必要のある方法である。identity続きはeipを直に読んだ方が良い。GitHub現状まだdraftのため、実装例はないが、アプリケーションをもっと軽くして、サインアップ手続きを減らしたり、既存のwebのようにもっと簡単に触れるようにしようということが狙い。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。