EthSign Twitter 上に発表された新しいバージョンのEthSignについての記事です。
文書に署名することは、実際には何を意味するのでしょうか？通常は、文書に記載された一連の条件に同意し、将来紛争が発生した場合に備えて証拠を残すことを意味します。
もっと単純化すると、署名という行為は、基本的に意思と同意を取得していることになります。意思は署名文書によって、同意は署名者の電子署名によって取得されます。
有効な署名を追跡するためには、文書に関する識別情報と、署名が本当に前述の署名者によって生成されたことを証明する証明書を保存する必要があります。
したがって、スマートコントラクトの文脈では、署名文書を指す固有の識別子と、暗号的に安全な署名の証明という2つの重要な情報を保存しなければなりません。
以前のEthSignでは、文書のハッシュ、署名者の生の楕円曲線デジタル署名（ECDSA署名）、文書の変更履歴と過去の署名履歴をそのままスマートコントラクトのストレージに格納することを選択しました。
しかしながら、これはガス消費という点で破滅的に厳しいものであることが判明しました。EthSign Signaturesでは、ガス消費量を減らすために、情報保存のアプローチを大胆に最適化しました。まず第一に、スマートコントラクト内に生のECDSA署名を保存しないようにしました。
一方で、EIP-712に準拠したECDSAによって署名行為が認証された場合に限り、記録保持データ構造を変更できるようにしました。
これにより、各署名の文字列を保存しないため、使用するストレージを大幅に削減できるだけでなく、EIP-712がpersonal_signを使用する以前のアプローチと比較して、署名にはるかに多くのコンテキストを提供するので、意思の取得もより容易になりました。
次に、スマートコントラクトのストレージ内に文書や署名の過去の状態が明示的に保存されなくなりました。 代わりに、それらはSolidityのイベントとして発行され、明示的なデータストレージと比較して消費するガス量がはるかに少なくなりました。
そして、それらは @graphprotocol によって提供される私たちのサブグラフによって取得されます。また、アップローダーが異なる署名者間の署名順序を指定できるように、署名順序のサポートも追加しました。
この追加した情報は他の関連する属性と一緒に保存され、最大限のストレージ効率を得るために一つのuint168にしっかりと格納されます
署名文書自体は@ArweaveTeamに@BundlrNetwork経由で保存されます。これはIPFSと比較して恒久的なストレージソリューションであり、MATICなどの他のトークンでArweaveストレージに保存費用の支払いを行うことができます。
キーレス暗号化機能を初日から展開し、ユーザーの秘密鍵*から派生した暗号鍵を使ったネイティブな暗号化・復号化を可能にします。
これはユーザビリティとセキュリティに対する大きな一歩です。文書は、AESキーを持っている人ではなく署名者のウォレットに固定されるため、（AESキーを生成する）パスワードを記憶して通信する必要性も当然なくなります。
以上の対策により、製品の完成度に悪影響を与えず、新機能を追加しながら、消費ガスを9倍削減することができました。