「Web3」カテゴリーアーカイブ

Warpcastを触ってみている

コメントを残す

少し前から気になっていた、Warpcastというアプリケーションでアカウントを作ってみた。
言ってしまうとX（旧Twitter）みたいなものだが、Web3。つまり、分散型のテクノロジーを組み合わせて作られている点が従来のものと異なる。

Warpcastとは

WarpcastはFarcasterという分散ネットワークを利用したソーシャルネットワークです。
見た目的には、ほぼほぼX（旧Twitter）ですね。
インターフェースとしてはモバイルアプリとWebがありますが、ログインはモバイルアプリから行う仕様となっています。

Farcaster に関しては本家のHPに仕様周りが書かれているが、ちょっとまだ正確に理解できているとは言えない。。。

Architecture | Farcaster

DAppsは各レイヤーに何が保存されて、どこで何を保証するのか？が分散化されているので、全体の理解という意味においては難しいですね。

見てくれは完全にXです

ブロックチェーンを使うことになるので、費用がかかってしまい、私がやったタイミングでは年間$5の費用が要求されました。

User、Channelsをフォローすることでタイムラインが賑わっていきます。
ただ、内容としてはXと変わらないので、Warpcast単独で使う分にはそれほどWarpcastをお金払ってやる必要性はないかもしれません。

費用がかかるため、スパムが入りづらいという点はあるかもしれませんね。

試しに、Castしてみました。

先々の利点

Farcasterでは、メッセージなどのデータをオフチェーンで管理し、IDに関する情報をオンチェーンで管理しているようだ。

アプリケーションは、Farcasterの上に構築されるアプリケーションとなるので、Warpcastと別のアプリケーション間でIDやメッセージなどを共有することが可能になる。
（アプリケーションの仕様として、他のアプリケーションで作られたメッセージなどを除外することももちろんできるだろうが）

複数のアプリケーション間で、同一のIDが同じユーザを指し示すことになるので、デジタル空間上のIDという意味では面白そう。

Ethereumメインネット上のWalletアドレスやENSを使えばいいんじゃないの？って話はあるが、

 It also uses a separate Ethereum account to sign transactions, so you can keep your main Ethereum account secure.

Accounts | Farcaster

別に作っているからかえって安全だよ、ということのようだ。
かなり、仕様の理解に関しては自信がないけれど、今のところの私の理解として書いてみた。
Warpcast以外のFarcaster上アプリケーションに関しても、せっかくなので触ってみようと思う

招待用のQRをちょっと貼り付けて見るので、もしよかったら使ってみてください。

参考

Goerli Testnet ETH Claim キャンペーン

コメントを残す

buildspace もようやく、 React のフロントエンドから Goerli Testnet にDeployしたスマコンに接続するところまで終了

途中、どうしてもうまくいかないな？と時間がかかる場所があったのですが、チュートリアルとしてその時点ではうまくいかない状態というオチでした。

時々ある罠ですが、ちょっと困るものです。。。

Goerli Testnet への Deploy は、以前にも誰ジェネでやってます。

誰でもできる！ジェネラティブNFT開発
https://crypto-code.jp/materials/create-generative-nft

ただ、その時もテスト用のEthが足りなくて、そもそもDeployできないという事態になったんですよね。結果としてその時は諦めてしまった過去があります。

そんな中、こんなTweetが！
過去に Mainnet / Goerli / Sepolia で Deploy したことがある人に 10 Goerli ETHをくれるという！

両手を上げて行ってみましたが、、、、 2022/11/15 時点でDeployしている必要があるとのこと。
そして、私がGoerliで試していたのが 11/16 。。。

Goerli テストネットワークでテストする準備

うがあああああああああ

という訳で、見事に対象外でもらうことができませんでした。。。
これは、ちょっとせつなすぎる。。。

いつものことといえばいつものことですが、本当に間が悪い。。。

どうにかならないものか。
どこかにお祓いに行ったほうが良いのかもしれません

Build an Ethereum dApp Section 1 clear

コメントを残す

buildspaceを引き続きやっています。
夜の時間をちょこちょことなので、進みが遅いですね。。。

hardhatを使った、ローカルでのスマートコントラクトの作成を追えて、フロントエンド開発としてReactを触り始めています。

Section2では、Replit というWeb IDEサービスを使って、フロントエンド開発を行っていくようです

Replit
https://replit.com/

最近、こういうブラウザベースのIDE。そしてそのままDeployまでできてしまうツールが増えてきていますよね。
なんかメニューを見ていたらこんなものも。。。

Ghostwriter・・・？
AIとのペアプロ？？

Meet Ghostwriter, your partner in code.
https://replit.com/site/ghostwriter

なんか面白そうですね。。。

色々なプロジェクトのチュートリアルをやっていると、その時の最新手法やツールなどを触ることができて面白いです。
実際の業務でこれらが使えるか？と言うと、なかなか悩ましいものがありますが、ちょっとしたお試しでやる分には十分そう。

問題はそのちょっとしたお試しと、それ以降の切り分けなのかな？
でも、それ以降に発展するところまで行ってから考えろって感じですね

buildspace で早速躓いていた

コメントを残す

色々と考えた結果、もう少しちゃんとdAppsを勉強していこうとbuildspaceの「Build an Ethereum dApp」をやり始めています

buildspace
https://buildspace.so/p/build-solidity-web3-app

そしてやり始めた矢先、一番最初のhardhat test が何故かエラーになる始末。。。

c:\Dev\buildspace\ethreum-dapp\my-wave-portal>npx hardhat test
npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead.
Compiled 1 Solidity file successfully


  Lock
    Deployment
      1) Should set the right unlockTime
      √ Should set the right owner
      2) Should receive and store the funds to lock
      3) Should fail if the unlockTime is not in the future
    Withdrawals
      Validations
        4) Should revert with the right error if called too soon
        5) Should revert with the right error if called from another account
        6) Shouldn't fail if the unlockTime has arrived and the owner calls it
      Events
        7) Should emit an event on withdrawals
      Transfers
        8) Should transfer the funds to the owner


  1 passing (2s)
  8 failing

  1) Lock
       Deployment
         Should set the right unlockTime:
     AssertionError: expected BigNumber { value: "1705326131" } to equal 1705326131
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:32:42)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at runNextTicks (node:internal/process/task_queues:65:3)
      at listOnTimeout (node:internal/timers:528:9)
      at processTimers (node:internal/timers:502:7)

  2) Lock
       Deployment
         Should receive and store the funds to lock:
     AssertionError: expected BigNumber { value: "1000000000" } to equal 1000000000
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:46:65)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at runNextTicks (node:internal/process/task_queues:65:3)
      at listOnTimeout (node:internal/timers:528:9)
      at processTimers (node:internal/timers:502:7)

  3) Lock
       Deployment
         Should fail if the unlockTime is not in the future:
     Error: Invalid Chai property: revertedWith
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:55:64)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  4) Lock
       Withdrawals
         Validations
           Should revert with the right error if called too soon:
     Error: Invalid Chai property: revertedWith
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:66:44)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  5) Lock
       Withdrawals
         Validations
           Should revert with the right error if called from another account:
     Error: Invalid Chai property: revertedWith
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:80:66)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  6) Lock
       Withdrawals
         Validations
           Shouldn't fail if the unlockTime has arrived and the owner calls it:
     Error: Invalid Chai property: reverted
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:93:48)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  7) Lock
       Withdrawals
         Events
           Should emit an event on withdrawals:
     Error: Invalid Chai property: emit. Did you mean "exist"?
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:75:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:106:14)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

  8) Lock
       Withdrawals
         Transfers
           Should transfer the funds to the owner:
     Error: Invalid Chai property: changeEtherBalances
      at Object.proxyGetter [as get] (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\node_modules\chai\lib\chai\utils\proxify.js:78:17)
      at Context.<anonymous> (C:\Dev\buildspace\ethreum-dapp\my-wave-portal\test\Lock.js:119:41)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

いや、まだロクに何もしていないのでこんなところでエラーが出るはずもないと思っているんだけど。。。という領域。

なんか、最近こういう、チュートリアルがそのまま動かずにやる気なくすというパターンが続くような気がする。
ただ、Discord見ているとできている人もいるので、なんだろう？
環境要因？？

Powershellで試してみた

うーん、なんでだろう？？と思って、ダメ元でPowershellでやってみたら。。。

PS C:\dev\buildspace\ethreum-dapp\my-wave-portal> npx hardhat test
npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead.


  Lock
    Deployment
      √ Should set the right unlockTime (1301ms)
      √ Should set the right owner
      √ Should receive and store the funds to lock
      √ Should fail if the unlockTime is not in the future
    Withdrawals
      Validations
        √ Should revert with the right error if called too soon (66ms)
        √ Should revert with the right error if called from another account
        √ Shouldn't fail if the unlockTime has arrived and the owner calls it
      Events
        √ Should emit an event on withdrawals
      Transfers
        √ Should transfer the funds to the owner


  9 passing (2s)

いや、おかしいだろ。

なんで コマンドプロンプトとPowershellで結果が違うんだよ。。。

かなりこれで時間つぶしてしまったぞ。。。畜生

walkenで垢バン食らった件とwalk to earnに関して

コメントを残す

タイトルどおりですが、walkenという walk to earn のアプリ。
平たく言うと、歩くことで稼ぐことができるという類のアプリをしばらく使っていたのですが、チート認定されて使えなくなりました。

というわけで、経緯とその考察。更に他の walk to earn アプリに関して書いてみようと思います。

walken で垢バン食らった経緯と対応

どこでこのアプリの存在を知ったのかはうろ覚えですが、すでにいくつか walk to earn を試していたので軽い気持ちでインストールしました。

walkenでは、比較的可愛らしいキャラクターを歩くことで育てていき、育てたキャラクターをユーザー同士でバトルすることができます。

先週から、急にそれまででは考えられないような強キャラクターが毎回対戦相手として出てくるようになり、何が起きているのかさっぱり。。。

そしたら、どうやらこれはチート扱いされているという言及を頂きました

むぅ。。。って完全にタイミング的にもアクアラインマラソン走ったことがきっかけか。。。確かにその日の歩数は5万は超えている。

と言うか、walk to earn なのに、マラソンで垢BANとか。ぐぬぬ

サポートへ連絡

サポートへ連絡という話だったので、walkenのDiscordに入って確認するとメールで問い合わせろと返事が帰ってきたのでメールで問い合わせ。

言われた通り、ヘルスケアアプリとかのスクリーンショットを送った結果

見事に玉砕しました。

なんやねん

考察

例えば、フルマラソンとか極端な例ではあるんだけど、walkenの場合はAppleのヘルスケアデータへアクセスして歩数を持ってきてしまうので、ユーザ側でその情報をアプリ側に渡さないということができません。

歩数がアプリを起動している間だけカウントされるとかであればユーザー側でやりようがあると思うのですが、これはどうしようもないです。

つまり、walkenはマラソンランナーが使うべきではないアプリとなります。
なぜなら、それまで育てていたキャラクターなどが無駄になるのではっきり言って時間の無駄です。

ただ、開発者の立場で考えると、仮想通貨というお金が絡む以上、何かしらのチート対策が必要となるのはわかります。
ヘルスケアアプリでは、歩数以外にもワークアウトの実績や距離に関する情報も取れると思うので、それらを踏まえて判断する形が良いのではないかと思います。

また、これらの長距離を走る人は、大抵ワークアウト用のアプリを入れています。
私であれば、Nike Run Club ですね。
これらのアプリと連携させることができれば、チート判別の精度は増すのではないでしょうか？

walk to earn で考えると、ランニングやマラソンを趣味としている人が、その趣味を活かせると考えて始めることにもなると思うと、現在の作りは残念で仕方がありません。

その他のアプリに関して

歩数をカウントする系統では、それ以外には、SweatCoinやMiles。DQウォークがを使っています。

SweatCoin

フルマラソン前後からちょっと歩数のカウント。特にBoostの動きが怪しいと思うようになりましたが、問題なく使えています。

こちらは今のところフルマラソンに耐えられるようですね。

Miles

そもそも距離の計測が最近まともにできていません。
以前は、それなりの精度でランニングなどを記録してくれていたのですが、ここ最近はそもそもランニングしても走ったと認知してくれなくなっています。

なんだか最近、やたらと広告も多くなってきたのと、使っていてもそれほどいいMileの利用先が無いのでそろそろ削除を検討し始めてます。

BitWalk、トリマ

この2つは一時期いれていましたが、広告の閲覧が前提となっていて、アプリで定められた出金の条件を満たす前に消耗するな、と考えてすでに削除済みです。

あくまで、ついでにコインを貯めることができたらいいよね！って程度の気持ちなので、これに必死になってしまうのは本末転倒ですし。

最後に

なんというか、ものすごっく気分悪いですが、エンジニアとして似たような人を産まないようなものづくりをしていかないといけないな、と考えました。

Goerli テストネットワークでテストする準備

1件のフィードバック

以前、cryptozombies でNFTやSolidityに関してのチュートリアル的な事をしたものの、それ以来全く触っていなかったNFT周りを改めて触ってみています。

今回は、その中で開発したコントラクトをテストするテストネットワークの一つ、Goerliテストネットを使ってみた話です。

テストネットワーク

今年の９月に実施された、 Ethereum 上の　The Merge。
これ以降、それまで使えていたKiln、Ropsten、Rinkebyは廃止され、現状でテストネットワークとしてはGoerliとSepoliaが用意されている形となります。

The Merge以前の学習コンテンツやチュートリアルでは、Rinkebyなどのテストネットワークを採用されているものが多いので、注意が必要となります。

といっても、基本的な扱いが変わるわけではないので簡単に説明します。

Alchemyの登録

テストネットワークでコントラクトを動かすために必要となるGoerliETHを手に入れるために、事前にAlchemyというサービスのアカウントを作成しておきます。

Alchemy
https://www.alchemy.com/

「Get started for free」から、適当に入力をしていくことでアカウントを作成可能です。

途中で、支払い情報などを入力する項目が出てきますが、特に入力せずとも問題ありません。

faucetでGoerliETHをリクエストする

GoerliETHのリクエストは下記サイトにて行います

GOERLI FAUCET
https://goerlifaucet.com/

右上にある「Alchemy Login」から、先程作成したAlchemyアカウントでログインを行うと

アドレスの入力とボタンが活性化されるので、ウォレットのアドレスを入力して「Send Me ETH」ボタンを押下します。

押した瞬間、私の場合はこんな趣味の悪いページが出てきました。。。

ほんと、なんというか変な罠を踏んでしまったかと思いました。。左上にバツボタンがあるので閉じれば問題ありません。

ウォレットで確認

無事にウォレットにGoerliETHが届いていました。

ETHの送金は、24時間に1度可能な形で、送金金額も特に変更はできませんでした。
それくらいのボリュームでテストをしなさいということなんでしょうか？
フリープランだからかな？

ガス代高すぎ？

ちなみに、試しにデプロイしてみようとしたら。。。

まさかの資金不足。

なんか随分とガス代が高い気がする？
そもそもテストネットのガス代って何で決まるんだろうか？
メインネットと同様に、テストネットワークの混雑度によって決まるのだとすると、GoerliとSepoliaでどちらが空いているかとか、考えたほうがいいのかな？