ソラナのトークンスキャナーは、あるアドレスが何を表すのか分かる前に、そのアドレスを発見する場合があります。見つけたものは、ミント、トークンアカウント、プール、または取引に関わる別のアカウントかもしれません。新しく観測したすべてのアドレスを、新しく作られたトークンとして扱うと、もっともらしく見えても、同じ種類の対象を説明していない記録が集まります。
順位を付ける前に、識別情報を整理します。スキャナーには「これはどの資産か」という問いへの長く使える答えと、「それについて何を観測したか」という別の問いへの答えが必要です。表示名は人が探す際に役立ちますが、元の識別情報の代わりにはなりません。正しい対象を示す発見記録のほうが、誤った資産へ詳しい得点を付けた記録より役立ちます。
Fernと表示される架空のトークンを考えます。発見用の配信には、三つのアドレスと、似た二つのシンボルが出てきます。この曖昧さを使い、アドレスを分類し、ミントを特定し、根拠となる証拠を保存し、市場やメタデータを資産そのものと混同せずに関連付ける、一連の識別手順を組み立てます。
Solanaトークンスキャナーではミントの識別を軸にする
ネットワークとミントアドレスを、資産の中心的な識別情報として使います。Fernという名前は便利な呼び名として残せますが、同じ名前を使う別の資産と区別する識別子を保つべきです。ネットワーク間でコピーした記録を、見慣れた文字列というだけで、黙って同じ対象にするべきではありません。
Solanaでは、ミント口座は、小数桁や権限など、トークンで共有する性質を持つと説明しています。一方、トークン口座は、ミントと所有者に対応する数量を保有します。この狭い区別が、分類の中心になります。Solanaのミントの文書とトークン口座の文書を参照できます。
最初の画面に、加工前の口座の詳細をすべて表示する必要はありません。しかし、分類を正当化できるだけの証拠は残す必要があります。あるアドレスが意図したミントだと確かめられなければ、シンボルの一致で穴を埋めず、候補を未解決のままにするべきです。
未解決の発見記録から始める
資産記録が完成する前でも、発見の記録は存在できます。どこからアドレスを得て、いつ観測し、情報源がどう説明し、どのネットワークに属するかを保存します。そうすれば、早まってトークンの対象範囲へ加えずに、候補を調べられます。
Fernの例で、ログのメッセージに含まれたアドレスが、後でトークン口座だと分かったとします。最初の発見は実際にありましたが、解釈によって意味が変わります。元の記録を残すと、最初からミントを直接観測したように装わず、そこへどうたどったかを確認できます。
これは収集の復旧中に特に役立ちます。過去の観測が、不完全な背景とともにまとまって届く場合があります。Solanaトークンスキャナーボットのガイドでは、追いつき処理でもイベントの識別を保つ方法を説明しています。その後で識別の手順を進めれば、到着時刻をトークンの作成時刻と混同せずに、記録を解決できます。
記録を結合する前にアドレスを分類する
記録を結合するとは、別々の観測が同じ対象を指すと決めることです。その判断は分類の後に行うべきで、先に行うべきではありません。二つの情報源が同じティッカーを示しても、一致は確かめられません。同じプールを参照する二つの観測も、その市場の反対側にある、違う資産を述べているかもしれません。
有用な分類記録には、口座の種類、プログラムの解釈、使った証拠を示します。あるトークンプログラムに対応し、別のものに対応しないなら、その境界を見えるようにします。完成して見える行を出すためだけに、未対応の口座を、最も近い見慣れた形式へ押し込むべきではありません。
以前のSolanaトークンの参入確認では、取引を提案する前に、プログラムとトークンの機能が重要な理由を説明しています。発見段階の直近の目的は、もっと狭いものです。そのアドレスがどの種類の対象か、資産へ関連付けられるだけ信頼して解釈できるかを知ることです。
Solanaトークンスキャナーの口座対応付けを関係として表す
トークン口座はミントを参照するもので、ミント自体の別のコピーではありません。関係を明示的にモデル化します。そのため、複数のトークン口座の観測が、一つの資産記録へ解決される場合があります。別々のトークンと数えると、発見数を増やし、対象範囲へ入った候補数の測定を歪めます。
トークン口座の所有者という役割は、その口座のデータ内の関係です。システムの階層で口座を所有するプログラムとは違います。内部記録でも読者向けの詳細でも、正確な名前を使います。一般的な「所有者」欄だけでは、情報源が違う関係を同じ語で呼ぶと混乱を招きます。
Fernについて、保有口座を二つ、ミントを一つ観測したとします。正しい結果は、三種類のトークンではなく、二つの口座へ対応付けた一種類のトークンになり得ます。各関係と観測時刻を残し、後の口座変化で、以前何を見たかという履歴が消えないようにするべきです。
関連トークン口座を新しいトークンと扱わない
関連トークン口座は、ウォレット、トークンプログラム、ミントへ対応付けられる、標準的な口座です。その作成は、口座のイベントです。それだけで、ミントが今作られたとは確かめられません。また、その資産の取引が始まったとも確かめられません。ある保有者が口座を必要とする、ずっと前からトークンがあったかもしれません。
したがって、把握している内容に合わせて、イベントに名前を付けます。「Fernの保有口座を新たに観測」と、「新しいFernトークン」は違います。新ミントを対象にするなら、口座作成イベントには別の選別条件が必要です。ウォレット監視が目的なら関係する場合もありますが、それでも正しい資産へ対応付ける必要があります。
Solanaのコインは何をもって新しいとするかの説明では、これらの節目を一つにしない理由を示します。正確な識別は、誤った新規性の原因を一つ減らします。別にイベント時系列を作ることで、ミント、プール、取引が、定義の下で本当に新しいかを扱います。
シンボルを検索できる呼び名として保つ
シンボルや名前は、検索と表示に役立ちます。しかし、重なったり、変わったり、情報源によって違って示されたりします。呼び名の出所と観測時刻を残し、検証済みの同じミントに、過去の複数の呼び名を対応付けられるようにします。名前は資産を探す助けであり、識別自体を決めるものではありません。
無関係な二つのミントが、両方FERNと表示される例を考えます。検索した読者には、区別するミント情報と、関係する情報源の背景を示すべきです。シンボル一致だけで統合すると、二つの異なる資産の価格、保有者、プール履歴、通知が混ざってしまいます。
同様に、名前の変わったトークンも、新しい表示名が現れたために履歴を失うべきではありません。識別を保ち、メタデータの変更を記録します。変わった名前が同じミントに属すと検証できなければ、元の関連が確かめられるまで、不確かさを明示します。
画像と説明文を未検証の表示情報として扱う
見慣れた画像や整った説明は、見覚えがあると感じさせる場合があります。しかし、どちらも資産の識別は確かめません。また、正当な資産であることも確かめません。見せ方が、検証したネットワークとミントの記録より優先することを避けます。検索結果からコピーする利用者が、実際に何を識別するアドレスかを調べられるべきです。
メタデータは、保証として扱わなくても役立ちます。中心となる口座の事実と分けて保存し、取得時刻を記録します。外部メタデータを使えなくても、表示情報が欠けた状態を付けて、検証済みミントを示せます。似た名前の別の資産で埋める方が、はるかに悪い結果です。
分けることで訂正も容易になります。誤解を招く画像を削除したり表示を変えたりしても、トークンの過去の観測を変えずに済みます。表示の層が変わっても、識別の層は安定します。見た目の編集で、発見からの経過時間をリセットしたり、重複候補を作ったりすることを防げます。
資産の識別情報と一緒に数量の単位を保存する
金額や数量を解釈するには、どのトークンなのかと、どの単位を使っているのかを知る必要があります。加工前の残高が、そのまま人の読めるトークン数量になるわけではありません。スキャナーは加工前の数量、表示に使う小数桁数、その定義の出所を保存するべきです。単位換算は、整形済みの文字列へ見えない形で埋め込まず、再現できるようにします。
仮に、小数点以下五桁を使うミントがあるとします。加工前の数量725,000は、トークン7.25単位を表します。別の配信元が7.25と表示していれば、加工前のアカウント記録と一致している可能性があります。換算せずに両方の値を比べると、実際には存在しない大きな差があるように見えてしまいます。
表示された数字の大きさや、同じシンボルを使う別のトークンから、小数桁数を推測してはいけません。単位の定義を間違えると、供給量、保有集中、流動性の推定、見積もりの比較へ誤りが広がります。候補を後続の順位付けや通知ルールへ渡す前に、識別情報の点検でこの問題を見つけるべきです。
ミントと、そのトークンを売買する市場を区別する
一つのトークンが複数のプールに参加することがあります。一つのプールには、そのトークンと別の資産が入っている場合があります。プールをトークンへ対応付けることは、市場との関係を記録することであり、プールのアドレスをミントのアドレスと同じものとして扱えるようにすることではありません。スキャナーはペアの両方の資産と、それらを識別した解釈方法を保存するべきです。
Fernについて、ある情報源がFern/SOLのプールを発見し、別の情報源がFernとステーブルコインのプールを発見したとします。検証後には、どちらも同じミントの記録へ関連付けられます。最初に見つかったプールのアドレスをトークンの恒久的な識別子にしてしまうと、後から見つかる市場を正確に結び付けにくくなります。
先行する新規ペアの検証ガイドでは、ペアを構成する資産と、プログラムの出所を説明しています。この境界では、それらの確認が役立ちます。市場との関連が主張されているなら、目的のトークンのシンボルが掲載タイトルにあるというだけでなく、解釈できるアカウントの証拠によって支えられるべきです。
権限を観測した時点を残す
権限は、ある時点で観測した属性であり、今後も変わらないことが保証された恒久的な注記ではありません。スキャナーが権限の状態を記録するなら、観測時の文脈と更新履歴を保存します。後の状態によって、候補が初めて対象に入ったときに読者が見た情報を、説明なく書き換えてはいけません。
解釈にも精密さが必要です。ある権限が存在しないことや取り消されていることは、特定の機能に影響する場合がありますが、あらゆるリスクが消えた証明にはなりません。スキャナーは、観測した権限がどの機能に関わるのかを説明し、一つの項目だけから広い意味の安全評価を与えるべきではありません。ほかのトークン機能、市場の状況、アカウントの許可も、なお重要である可能性があります。
ソラナの新規トークンスキャナーのガイドでは、権限の変更を時系列で扱っています。識別情報を整理する作業によって、そうした時系列を作るための安定したミントの記録が得られます。この基準がなければ、権限の更新を名前の似た別の資産へ付けたり、新しいトークンの発見だと誤解したりする可能性があります。
未対応の機能は推測せずに明示する
トークンの機能は、アカウントをどう解釈するべきかや、対応している処理の中で資産がどう動くかに影響する場合があります。ソラナのトークン拡張は、ミントやトークンアカウントへ任意の機能を追加します。スキャナーは、すべてのアカウントが最も単純な解析手順に従うと仮定せず、実際にどこまで解釈できるかを明示するべきです。ソラナの拡張機能の文書。
機能の存在は認識できても、その影響を評価できないなら、そう説明します。「機能を検出したが、解釈には未対応」という状態には意味があります。これによって、アカウントの取得に成功したことを、資産を十分に理解できたことだと後続の構成要素が誤解するのを防げます。データを取得することと、それを正しく解釈することは、別々の達成事項です。
解釈できる範囲には版を付けるべきです。対応範囲が広がったとき、スキャナーは新しい版で未解決の記録を調べ直せます。過去の状態も残します。過去の研究が反映するべきなのは、後の解析機能が保存データから推測できる内容ではなく、その当時にシステムが理解していた内容だからです。
情報源同士の主張が食い違うときに照合する
二つの情報源が、アドレス、ラベル、アカウントの種類について食い違うことがあります。項目数が多いほうの情報源を選ぶだけで、食い違いを解決してはいけません。元になった証拠、ネットワーク、観測時刻、解釈方法を比べます。詳しい記録でも、誤っていたり古くなっていたりする可能性があります。
Fernについて、ある掲載情報がプールのアドレスをミントだと記し、アカウントを読み取った結果では、別の場所を参照する保有用アカウントだと分かったとします。スキャナーは両方の主張を残し、食い違いを明示し、その関係が解決するまで市場データの結合を避けるべきです。この食い違いは、隠すべき不都合ではなく、研究記録の一部です。
訂正では、どの関連付けが変わり、どの派生記録へ影響するかを説明するべきです。誤った識別に基づく価格、通知、保有者数には、点検が必要な場合があります。誤りがすでにスキャナーの過去の対象集合や後続の計算へ広がっているなら、表示名だけを直しても十分ではありません。
資産、アカウント、発見を別々に数える
役立つダッシュボードでは、届いた発見イベントの数、分類できた重複しないアドレスの数、ミントを特定できた資産の数を示せます。これらは別々の件数です。その差を見ることで、重複した配信、同じアカウントの繰り返しの観測、識別情報を解決する作業を調べやすくなります。
架空の収集期間に、重複を除く18個のアドレスについて40件の発見イベントがあったとします。十二個のアドレスは四つのミントへ対応するトークンアカウントで、四つのアドレスはそのミント自体、二つは未解決です。スキャナーに証拠があるのは、識別を解決できた四つの資産であり、十八個や四十個の資産ではありません。未解決の記録は見える形で残しつつ、確認済みトークンの数へ加えてはいけません。
この数え分けは、作業の進み具合を測る際にも役立ちます。以前から不明だったアドレスを解決すると、チェーン上で新たな作成イベントがなくても、既知の資産の数が増える場合があります。その変化は、分類が改善した結果として表示します。読者が、スキャナーの完了した作業を、ネットワーク上の新たな経済活動と混同しないようにするべきです。
訂正も識別情報の履歴として保存する
識別情報の記録には、訂正が必要になることがあります。解析機能がアカウントを誤分類する場合も、情報源が誤ったネットワークを示す場合も、結合ルールが二つの資産をまとめてしまう場合もあります。後から追える訂正では、以前の関連付け、新しい関連付け、理由、影響する期間を記録します。説明なく置き換えると、後の研究を監査しにくくなります。
誤って統合された記録を分けるときは、どの観測がどのミントに属するかを保存します。一部は、曖昧なまま残る場合があります。データベースを完全に見せるためだけに、過去のすべての項目を、識別が解決した資産へ無理に割り当ててはいけません。根拠のない割り当てをもう一度行うより、解決していない部分を正直に残すほうがよいのです。
先行するソラナ取引の基礎ガイドでは、アカウント、交換、照合を結び付けています。アカウントの履歴と取引の履歴は資産を正しく識別できることに依存するため、識別情報の訂正はそこでも重要です。発見は上流で担う仕事であり、その誤りは思いのほか遠くまで広がる可能性があります。
意図的に曖昧な事例を使って処理を試す
十分な識別情報の点検には、表面的に照合する仕組みが混乱するように作った事例を含めます。同じシンボルを持つ架空の二つのミント、過去に二つの名前を持った一つのミント、一つのミントを参照する複数のトークンアカウント、トークン名に似たラベルを持つプールを使います。できあがる記録が、意図した区別を保っているか確認します。
誤ったネットワークの記録と、未対応のアカウント形式も加えます。望ましい結果は、すべての事例が自動で解決することではありません。一部は、理由が分かる未解決の状態に残るべきです。常に確信のある識別結果を返すスキャナーは、強引な照合ルールの内側へ不確実さを隠しているだけかもしれません。
トークン発見時の識別確認では、後続の動作も検証するべきです。ミントが確認済みであると仮定する順位付けへ、未解決の記録を入れてはいけません。関連付けを訂正したときは、訂正履歴を保存しながら、影響する派生表示を更新するべきです。この境界を試すほうが、ページに名前がきれいに表示されるかを見るより価値があります。
インターフェースでアドレスをコピーする境界を点検する
保存された識別情報が正しくても、読者が誤ったアドレスをコピーすれば失敗することがあります。詳細ページには、ミント、プール、複数の関連アカウントが近くに並ぶ場合があります。コピーの操作には対象の種類を表示し、選択したネットワークも示します。そうすれば、受け取る処理へ意図した識別子を渡せます。
架空のFernの記録で、プールのアドレスをミント検索へ貼り付けたなら、説明や、対応している解決手順を示すべきであり、名前が空の新しい資産記録を作るべきではありません。同様に、別のネットワークから貼り付けたアドレスは、文脈が確認されるまで、検証済みの資産識別情報の外に置きます。こうしたインターフェースの確認によって、データモデルですでに設けた区別を守れます。
発見メッセージから資産ページを経て、識別子をコピーするまでの、ひと続きの経路を点検します。読者がアドレスの役割を知るために、画面内の位置から推測する必要があってはいけません。受け渡しが明確なら、精密な内部記録が、誰かが使う瞬間に曖昧になることを防げます。
完成した記録を読者が理解できる形にする
完成した資産記録は、いくつかの具体的な問いに答えるべきです。どのネットワークとミントがそのトークンを識別するのでしょうか。どのラベルが付いていて、どこから来たのでしょうか。どのアカウントとプールが関連しているのでしょうか。何が未解決なのでしょうか。証拠はいつ観測され、どの解釈の版がその関係を作ったのでしょうか。
それらの答えを示すために、技術情報を詰め込んだ画面は必要ありません。簡潔な主表示で資産の識別情報と状態を示し、詳細表示で関係を説明できます。重要な設計上の選択は、区別を確認できるようにすることであり、一つの一般的なアドレスと一つの確信度の得点へ押し込めないことです。
ソラナのトークンスキャナーは、識別情報を、点検して訂正できる証拠として扱うことで、より役立つものになります。その結果、順位付け、通知、研究は、時間がたっても同じ意味を持つ記録を使えます。それでも、スキャナーはトークンの安全性や将来性を保証できませんが、次の問いを検討するための、はるかに確かな基礎を築くことはできます。