DepositLog concerns
samczsun opened this issue · 4 comments
Description
Two concerns with DepositLog
- Timestamps are logged even though you can look it up from the event block number
- The funding txid isn't logged, but the redemption txid is
Ceding this to you @Shadowfiend
🤔 okay, finally had time to dig here a little bit. Strictly speaking, yes, you can get the timestamp from the block. Ergonomically, though, this is a bit of a dumpster fire. You have to expose, in whatever API you implement client-side wrapping this stuff, enough information to derive the timestamp (be it the timestamp itself, the block number, a container for all the block metadata, whatever), and that's actually not easy to do at the API exposure level (e.g. tbtc.js), and also annoying to manage at the application level, because…
Right now, the direct APIs for access to event info include various bits of block information, but typically not timestamps (e.g. web3 returns block hash but not timestamp, ethers.js exposes a function fetch the block metadata). For tBTC specifically, timestamps have first-class application importance, since they relate to timeouts that can trigger external action. That means there's the potential for certain application types (e.g., liquidation monitors) to need to query the block information each time a new event comes in, just to get the timestamp. Typical Ethereum API providers will charge ~per request on this kind of stuff. So there's high value to avoiding that extra request. There are ways to twist oneself around this, of course, by pairing a block monitor with the event monitor and locally caching the info, etc, but I think we do enough contortion just to interact with Ethereum in the first place… It'd be nice if we made this particular thing immediately straightforward.
All of that to say: I don't think we should drop timestamps from events. I do agree we should log funding txids.
@mhluongo are you comfortable with this tradeoff? If yes, I'll leave closing the issue to you. This sort of straddles the technical product side of things since it percolates to APIs, so wanted to get an explicit signal rather than closing unilaterally.