Discussions

Hey there, as you might have known, I'm working on <https://github.com/9oelM/hooks-rs> which is a Rust project that compiles Rust code into hook-compatible wasm. And I was working on some XFL support for one of my pull requests at <https://github.com/9oelM/hooks-rs/pull/11> with an integration test containing the problematic hook. While testing, I came across a very strange behavior of XRPL node when it validates hooks. Basically, if I add a bit more code that is supposed to be functional and working like any other code, it will suddenly stop the node from validating the hook. The preliminary observation (could be totally wrong) is that if I add too many block statements in the wasm file... the node will not validate my hook? The issue contains all the payloads and the details so please check it out. I've been wrestling with this for a while but couldn't really find meaningful solutions. I know it sounds like a rough summary and it is, so please do have a thorough read of the code and the Github issue: <https://github.com/9oelM/hooks-rs/issues/12>

Attempting to play with rippled/hooks for first time. Using direction from following repo: <https://github.com/XRPL-Labs/xrpld-hooks/tree/hooks-ssvm> After running container, seems like rippled node is running, but network state is disconnected when queried. Attempting to run/install any of the included example hooks results in : disconnecter, code: 1000, and RippledNotInitializedError. Any chance someone could point me in the right direction here?

Hi there, I just have a question about the execution of the hook. So the first question would be: can the same hook that belongs to the same hook account execute concurrently if it receives multiple transactions from different accounts within a short time period, or at least start at different times and end at different times, but still have an overlap of the time in which they are executed? If the answer to the first question is no, you don't have to answer the next question because it is the premise of the next question. The next question goes like this: Let's say you mutate a state by using `state_set` in your hook. And you invoke the hook many times within a short period of time by sending several transactions to the hook for which it is installed to be invoked upon. Then is the mutation of the state always atomic? For example: ``` #include "hookapi.h" int64_t hook(uint32_t reserved) { uint8_t key[32] = {0}; int64_t count[1]; int64_t state_read_result = state(SBUF(count), key, 32); if (state_read_result == DOESNT_EXIST) { count[0] = 0; if (state_set(SBUF(count), key, 32) <= 0) { rollback(SBUF("failed to set count"), -2); } } else if (state_read_result <= 0) { rollback(SBUF("failed to read state"), -1); } else { count[0] += 1; if (state_set(SBUF(count), key, 32) <= 0) { rollback(SBUF("failed to set count"), -2); } } accept(SBUF(count), 1); _g(1, 1); // every hook needs to import guard function and use it at least once // unreachable return 0; } ``` And let's say 100 different accounts invoke the hook approximately within the same second, and the hook runs for those people approximately within the same time range. I am asking if it is possible that the `count[0]` is NOT `100` after all of successful 100 executions. I was designing some vault stuff using `state` and came to a conclusion that state mutation has to be atomic in order for all the hooks to be secure. But I couldn't find that in any of the documents, so I just wanted to confirm. KP

When XRPL HOOKS will be ready to use for Rust? If it is available where can I get the documentation to get started? Is this HOOKS can perform all smart contract functionalities on Ripple chain?

"typically hooks are written in c" I see all the examples and docs are in c. You prefer people to write in c? How do the examples compare/port over to other languages for hooks?

1. I would like to know If I can block the incomming transaction addr is a blacklisted one 2. How can I know if a particular addr already made a sucessful tx with me. Do I need to create a list , and how do I map and filter to them. Note : I am not from the C background, mostly javascript and java. please help Thank you.

Hi there is a question that has been in my mind for some time. https://github.com/XRPL-Labs/xrpld-hooks/discussions/57 I ask the question again here, because I think it is an important one. about "C inline functions" and the compiler option to force compile "always inline". There is a possibility to enable this functionality? Inline functions, I know, can be an alternative to the awful macros. recursion is not possible with inline functions and the benefit could be a programming style very similar to javascript and solidity. thank you

platform: "nodejs" lib: "xrpl - ^2.5.0" I'm trying to print out all transactions made by a specific account but its showing 2 transactions even though I only sent one. I understand some what that there is in essence outgoing and incoming transactions. - from my source code what changes are needed to filter the sending account to show all outgoing transactions? - why am I seeing 2 transactions? - do i just need to filter by account? but then how do I differentiate the direction? thanks, sedo: 1) connect 2) create and fund sender and recipient 3) submitAndWait for transaction 4) request "account_tx" full code: ` const TESTNET_SERVER = 'wss://s.altnet.rippletest.net:51233' // Define the network client const client = new xrpl.Client(TESTNET_SERVER) await client.connect() // Derive a wallet from a bip39 Mnemonic - cold address - issuer const senderWallet = xrpl.Wallet.fromMnemonic(getMnemonic()) await client.fundWallet(senderWallet) // Derive a wallet from a bip39 Mnemonic - hot address - regular user's address const recipientWallet = xrpl.Wallet.fromMnemonic(getMnemonic()) await client.fundWallet(recipientWallet) var result = await transfer(client, senderWallet, recipientWallet) // Check transaction results ------------------------------------------------- console.log("Transaction result:", result) const tx_response = await client.request({ "command": "account_tx", "account": senderWallet.address, "validated": true }) console.log(tx_response) console.log( '*************************' ) console.log(tx_response.result.transactions) // Disconnect when done (If you omit this, Node.js won't end the process) client.disconnect() ` output: ` Transaction result: tesSUCCESS { id: 21, result: { account: 'rD9zvrG9G62UtzZtaUteaENTV7SgEdJqof', ledger_index_max: 32544985, ledger_index_min: 32476837, limit: 0, transactions: [ [Object], [Object] ], validated: true }, type: 'response' } ************************* [ { meta: { AffectedNodes: [Array], TransactionIndex: 3, TransactionResult: 'tesSUCCESS', delivered_amount: '1000000' }, tx: { Account: 'rfTxspF3GiroFd3Hfay2Th92kfVthDPenP', Amount: '1000000', Destination: 'rD9zvrG9G62UtzZtaUteaENTV7SgEdJqof', Fee: '12', Flags: 0, LastLedgerSequence: 32545003, Sequence: 32544980, SigningPubKey: '03315108259B667674B193C51691F16901BE10783BD612A8343FED94EB56FBFC25', TransactionType: 'Payment', TxnSignature: '304402207D8263B69C2C08AF06A1AD84C14055655DA0DFF2106B91AE3C33CD70365ABFE3022000E71A788AD60A451CC7D6E438CF029AA474087632627C07F59E0CB735DFD7ED', date: 720772413, hash: 'CF091E1871A1972EC9FC8252E4AD9D3C40893F2CA3B3B821B3D56D2E77B1688C', inLedger: 32544985, ledger_index: 32544985 }, validated: true }, { meta: { AffectedNodes: [Array], TransactionIndex: 1, TransactionResult: 'tesSUCCESS', delivered_amount: '1000000000' }, tx: { Account: 'rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe', Amount: '1000000000', Destination: 'rD9zvrG9G62UtzZtaUteaENTV7SgEdJqof', Fee: '12', Flags: 2147483648, LastLedgerSequence: 32544986, Sequence: 4414467, SigningPubKey: '02356E89059A75438887F9FEE2056A2890DB82A68353BE9C0C0C8F89C0018B37FC', TransactionType: 'Payment', TxnSignature: '304402203EC0CEF2BEDDBEFA3093E5F9E951A55C514A780C06AD3A560BCEB1E9535E2F2602207E807454B35CC278D4437285DD457A0743145E5DE0702617BF5AA64CEDA0FED5', date: 720772411, hash: 'B36F8491C4235EF137E243DFF8A3273BE3FED544217B346D51DEF4AA7AF791C6', inLedger: 32544983, ledger_index: 32544983 }, validated: true } ] `

Is there anyway to prevent a hook from being deleted? my thought process: I don't want a user to be able to remove the hook... so if an account is compromised and the seed/keys land up in the hands of a malicious user. that malicious user should not be able to remove the hook... can a hook be programmed to check some state before being removed/overwritten and act upon that state? is there any sort of OnRemove(); BeforeRemove(); very broad question so im open round about ways. thanks,

Hi In 3 chained transactions test, where the 1st ordinary payment txn triggers the 2nd emitted, and the 2nd triggers the 3rd, I see that the 2 emitted transactions have the EmitGeneration field = 2(the 2nd) and 4(the 3rd) 1st txn https://hooks-testnet-v2-explorer.xrpl-labs.com/tx/D8868FF6761DACA9A704A98D9CD3225BC82E914B507364ECA4D273F919C4712B 2nd emitted txn triggered by the 1st https://hooks-testnet-v2-explorer.xrpl-labs.com/tx/47CDEC6EBA4AAEA9E640643C4A6ACAFF09E63DBE093138F10847EA407509ACE7 3rd emitted txn triggered by the 2nd https://hooks-testnet-v2-explorer.xrpl-labs.com/tx/AF372886C4A3297A0137B43D6C3C823180A69779F060228D27C33F5DE015906F But, according to the documentation, I should see values of 1 and 2 https://xrpl-hooks.readme.io/docs/emitted-transactions#emitdetails-block fields are filled by etxn_details() etxn_reserve always = 1 EmitBurden always = "1" seems correct