You are viewing a single comment's thread from:
RE: How Steem Witnesses can help the SVM Dream . Bridging SVM to Steem: A Witness-Based Bridge Oracle
@cur8 @steem-agora @blaze.apps
Do we really want to have the results of one LLM evaluated by another LLM here, and decide on a HF based on that?
I have a few basic questions:
- Have you successfully compiled the code?
- The Steem witnesses are supposed to monitor the SVM feed. What is the SVM feed? How can the witnesses access it?
- What happens to the remaining STEEM if the initial account/user on SVM sells part of its STEEM? Example: 200 STEEM goes to the
svm.bankaccount, 50 STEEM are sold, 150 STEEM are burned on SVM, 150 STEEM are repaid. What happens to the remaining 50 STEEM that were sold on SVM? - Why are you using a fixed gap of 22 blocks? Why not make it dependent on the irreversible block?
And I have a few more first thoughts:
svm.bankshould not accept SBD. In the event of interest payments, it is unclear how these will be repaid.- I'm not convinced by the
bridge_submit_operation. I have to agree with Claude (No. 6). That generates a lot of spam. Perhaps there are alternatives.
Hello @moecki ,
Yes i compiled the code successfully and i have a public testnet now rpc exposed to https://testnet.blazeapps.org. The code is not 100% by LLM , its howerver built using LLM . THE SVM Withdrawl feed is an api endpoint that responds all SVM based withdrawls . SVM Nodes has api endpoint
/steemvm/steembridge/v1/pending_withdrawals, each withdrawl has a id and is incremental (N+1) . The STEEM sold on the SVM Dex or moved out to other chains Through IBC stays in the svm.bank . Burnt STEEM on TX fees are Chains Revenue , SVM -> Steem miannet is a user driven event in SVM when a users calls specific function to bridge back X amount of STEEM or SBD . Interest payments is co-ordinated , SBD can also have interest . Yield is possible on SVM but has to go through a Gov Proposal . Spam can be mitigated by applying a certain percent fees on the bridge both way . I put it ( 21 + 1 ) block because 21 blocks is the standard mathematical round in the DPoS scheduleThanks for your reply.
nice to see your testnet running. 👌
Okay. Is it correct that witnesses need to run a separate script if they want to monitor the feed? Would almost all witnesses do that? Note that there is also one non-top witness included. In that case, at least 17 of the top 20 witnesses must monitor the feed continuously (or at least once every 3.5 days).
I don't know how does the witness node receive the information that it should now authorise the payout? I wasn’t able to test this, as I didn’t receive any results from the endpoint. Is it correct that a GET request must be sent to https://evm.blazeapps.org/steemvm/steembridge/v1/pending_withdrawals ?
Hm, isn’t that a problem? That means there’s no synchronisation between the account balance on
svm.bankand the SVM supply. How should this be handled if a STEEM buyer on SVM wants to withdraw their STEEM from the mainnet?You mean that if interest is paid on the mainnet, it will also be paid on the SVM? Who or what is supposed to ensure that they run in parallel? That seems too uncertain to me. Even a slight deviation can lead to different amounts. Is interest on STEEM also planned for the SVM? Probably for all sorts of tokens, right?
Yes, that's good. But perhaps a percent fee with a minium amount would be better for micro returns (e.g. for 0.001 STEEM?).
Okay, but then we should use the existing constants to define these things. Or new constants defined by the existing constants. But that's a matter of code review. There are some odd uses.
Hi @moecki , yes the proposed Approach requires all witnesses to monitor the feed and report the bridge events , Similar to how it is actually required for them to run the price feed . This approach assumes witnesses are concerned about the Bridge as much as they are concerned about the price feed .
I missed to copy whore url for the rest api server , you can get
The Assumption and recommendation is that witnesses run their own node so the data they get is through directly querying the chain rather than relying on the third party api who can be dishonest as well .
If svm.bank starts receiving interests on SBD , Validators may propose a Governance proposal to pay SBD interests on SVM and it comes from inflation , only if the validators are able to pass the proposal . If not svm.bank will be holding surplus SBD , It wont be a problem that svm.bank has more balance than the circulating supply of steem and sbd on svm . the opposite should never happen . Both STEEM and SBD on svm can generate yeild , provided validators change inflation rate which is 0% at genesis .
Yes , We can add a minimum withdrawl , hard code and also add a additional fees on bridge events which can be burnt maybe , its just hypothesis , the current code is 1:1 and no fees or minimum is set , but its an easy addition i believe .
The birdge reuses some constants and introduces some
STEEM_BRIDGE_ORACLE_LIFETIME_BLOCKS re uses STEEM_BLOCKS_PER_DAY * 7 / 2)
STEEM_BRIDGE_ORACLE_MAX_CANDIDATES = 3
STEEM_BRIDGE_ORACLE_MATURITY_BLOCKS (STEEM_MAX_WITNESSES + 1)
Hello @moecki , Chain has recently been upgraded to a newer version supporting these proposals for the SVM testnet . so the new withdrawl api endpoint is https://reststeemvmd.steemscanner.com/steemvm/steembridge/v1/requested_withdrawals