Miki Q&A

Deposit and Execute:

特定の場所に預けた資産を元に他のチェーンでtxを実行することができる。例えるとデビットカード。

認識はその通りで、intents的に考えるとescrowを取引ごとではなく、事前にまとめてescrowしてそれをトランザクションを実行するたびにリリースしていると言い換えることができると考えています。

Asset Yield Generation:

特定の場所に資産を預けるだけでMikiが勝手に運用してくれる？

初期の設計ではMikiが運用することにしていました (ex. Lidoでステーキングする)。ただ、Mikiが運用する場合はユーザーが資産を預けるカストディアルの形式を採用することになってしまい、ハッキングのリスクなどでユーザーに受け入れられない可能性を危惧しています。そのため、セルフカストディアルにするために既存のLST (ex. LidoのstETH) やLRT (ex. RenzoのezETH) をガス代やブリッジのアセットとして取り扱えるようにした方がいいのでは？と考えています。

ただ、「トークンを運用しつつガス代やブリッジに利用できる」という部分は変えないで、それをMiki自体で資産を管理して運用するか、それともユーザーがYieldが発生するトークンを自分で持ちつつ、それをトランザクションに使用できるようにするかをどうするかはまだ議論の段階です。

Pull-based Core

上でも述べたように資産の情報の管理をHub Rollup (Arbitrum) で行っているので、Ethereumの情報を取得する必要がないので、Futabaを使用しないです。

補足

初期の設計では、Ethereumに資産だけでなく、どのユーザーがいくら預けているなどの資産の情報自体も管理するようにしていました。ただ、その場合Ethereumのガス代が常にネックとなり、そのためのバッチ処理などでかえってUXを下げることになると思ったので、現在ではHub Rollupで取引の情報や資産の情報管理をするような設計にしています。そのため、極力Ethereumとのインタラクションはしないようにしており、Futabaによるデータ取得やdeposit/withdrawのバッチ処理をしないようにしています。

HubからSpokeへのBridgeに時間がかかるのでは

非常に妥当な指摘です、、、笑

そのため、チェーンを跨いだ共通のmempoolにユーザーがintentsを送信する方式にして先に対象のチェーンのトランザクションを実行し、実行が成功したらsettlementを実行する方式に変更しようと考えています。

ラフな図 (アイデアの段階)

https://scrapbox.io/files/663218f13cb2d7002716481d.png

ただ、完全に既存のmessagingが必要なくなるとは考えていません。上記の仕組みにおいてユーザーが実行したいトランザクションの実行はそもそもmessagingのようなcross-chainの形式で行われる必要がなく、重要なのはescrowのトランザクション (上の図の3) と本来実行したトランザクション (上の図の4) のatomicityを保証することです。一方で、ガス代や資産を肩代わりしているsolverに対しては4のトランザクションが成功したことをescrowのコントラクトに伝達し、escrowされた資産をsolverに返却する必要があります。これを保証するためにはmessagingを利用した方が、適切だと考えています。それはこのsettlementの処理にはスピードよりも必ず情報が伝達されるという実行保証の方が重要だと考えられるためです。もし、このアイデアについてもっとよくできる部分などがあれば教えていただきたいです🙏

長くなってしまいましたが、最初に共有したものとは異なるアーキテクチャに今後なる可能性がありますが、messagingやbridgeのような部分的なパーツは例え大きくアーキテクチャが変わったとしてもそのまま転用できると思っています。

* English version

Deposit and Execute:

By depositing assets in a specific location, you can execute transactions on other chains. It can be likened to a debit card.

Your understanding is correct. In terms of intents, we can rephrase it as batching the escrow in advance instead of per transaction, and releasing it each time a transaction is executed.

Asset Yield Generation:

Do you just deposit assets in a specific location, and Miki automatically manages them?

Initially, the design was for Miki to manage the assets (e.g., staking on Lido). However, if Miki manages the assets, it would necessitate a custodial model where users deposit their assets, which may not be well-received due to the risk of hacking. To make it self-custodial, we are considering allowing users to use existing LSTs (e.g., Lido's stETH) or LRTs (e.g., Renzo's ezETH) as gas tokens or bridge assets.

However, the aspect of "being able to use the yield-generating tokens for gas or bridging" remains unchanged. The discussion is still ongoing on whether Miki should manage and operate the assets itself or allow users to hold yield-generating tokens and use them for transactions.

Pull-based Core

As mentioned above, since we manage asset information on the Hub Rollup (Arbitrum), there is no need to retrieve information from Ethereum, so we do not use Futaba.

Additional context

In the initial design, we planned to manage not only the assets but also information on which users had deposited how much on Ethereum. However, we realized that Ethereum gas fees would always be a bottleneck, and batch processing for this could actually degrade the UX. Therefore, in the current design, we manage transaction information and asset information on the Hub Rollup. As a result, we try to minimize interactions with Ethereum and avoid using Futaba for data retrieval or batch processing of deposits/withdrawals.

Wouldn't it take time to bridge from the Hub to the Spoke?

This is a very valid point.

Therefore, we are considering changing to a model where users send intents to a common mempool across chains. The target chain's transaction will be executed first, and if it succeeds, settlement will be performed.

Rough diagram (at the idea stage):

https://scrapbox.io/files/663218f13cb2d7002716481d.png

However, we do not believe that existing messaging will be completely unnecessary. In the above model, the user's intended transaction does not necessarily need to be executed in a cross-chain format like messaging. The important aspect is ensuring atomicity between the escrow transaction (3 in the above diagram) and the intended transaction (4 in the above diagram). On the other hand, for the solver who is subsidizing the gas fees and assets, we need to convey to the escrow contract that transaction 4 has succeeded and return the escrowed assets to the solver. To ensure this, we believe using messaging is more appropriate since execution guarantees are more important than speed for this settlement process. If you have any suggestions for improving this idea, please let me know.

Although the architecture may change from the initial design I shared, we believe that components like messaging and bridging can still be carried over even if the overall architecture changes significantly.