Hot answers tagged

9

This is what I understand after a quick walk, through the code. Your usage status is checked and updated on the chain only when an action​ is done with your account.( This is intuitive, when I look back, because updating all the account usage statuses periodically will be a huge load on the blockchain) So what you see when you check your usage is the ...


6

EOS account can choose to buy ram or cpu? Can they not buy any at all? You need RAM for the nodes to store data about your account,--including account name, public keys, and other meta-data--in the blockchain state. CPU and NET are needed for executing the transaction that creates your account and storing that transaction on the blockchain, respectively. ...


5

libraries/chain/include/eosio/chain/config.hpp#L48-L49 static const uint32_t account_cpu_usage_average_window_ms = 24*60*60*1000l; static const uint32_t account_net_usage_average_window_ms = 24*60*60*1000l; I interpret this to be 1.000 day wall clock time.


3

By default, Nodes have a config for max-transaction-time = 30 but it doesn't necessary for all Bp to have exact same config for max transaction time so they can change at any time. ::get_resource_limits() is privileged API, so it cannot be used by normal account (only privileged account can call it like eosio) You can get the limit of cpu, net or ram by the ...


3

If transaction fails - it will fail on first validating node. It will not reach block producing node at all. Which mean there is no way this account can be charged for broadcasting bad transaction. And AFAIK the same goes with bitcoin and ethereum. Do you have other information?


2

Several things: You can setup your contract such that users pay for the RAM they use; You can require an on-chain fee in EOS from users or off-chain fees when people sign up to your service; You only need to pay for AWS/cloud storage if you're storing significant off-chain data that you can't store locally and you can't use the upcoming IPFS integration (in ...


2

your cleos command looks absolutely right. if your transaction did not appear on the blockchain - may be it's because it was accepted by your node (the one that gave you transaction hash), but was not accepted by any of block producers. why? may be you was on the edge of your CPU time and it was enough to run your transaction on your node, but not enough to ...


2

Just a quick shot: Search for blocked/still available names and namespaces like it's done when buying an domain online Cost calculator for creating an account


2

Great idea, I would love to use that. If you need any help, I may use some spare time to participate. in addition to 5. voting: stats for BPs (e.g. how long have they have been active as BP, missed DPoS turns etc.) history of voting for freezing accounts, change account code, protocol/constitution changes 8) When added to EOSIO, information about EOS ...


2

confused00 should have made this response as he/she is correct. RAM must be freed before you can sell it. For a dev this means you have to release your claim on the RAM to sell it For an end user this means you need to see how the application you're dealing with has consumed your RAM and execute the command that is hopefully there to "free" that RAM so ...


2

If you want to log events on chain, you can use the demux-js library on the eosio repo to listen to chain events. From here, you can store that data as it updates in your database of choice.


2

print() appears to cost CPU cycles and expensiveFunction() is evaluated. I tried with the following. As there is no sleep I just looped (the expensive function takes about 50 ms > 30 ms allowed on the test node). This results in Error 3080006: Transaction took too long string expensiveFunction() { int volatile i = 0; for(; i<600000;) { i++; ...


2

Testing with v1.5.1, adding a new permission to an account (set account): Corresponding contract action: updateauth RAM: 32 bytes NET: 185 bytes CPU: 320 time for set action permission: Corresponding contract action: linkauth RAM: 144 bytes NET: 127 bytes CPU: 664 time Important to know: Ram usage is about using the storage, that means if update a ...


2

For v1.5.1 an account that won't perform any action (including transfer) you don't need to delegate CPU/NET. Bare minimum amount for new account is 3 kbytes with the current reward for newaccount which is 1.5 kb (article from Dan). Which require the creator to buy 1608 bytes. --stake-net="0.0000 EOS" --stake-cpu="0.0000 EOS" --buy-ram-bytes=1608 Results: ...


2

Your idea is along the right lines. Either do batch updates, where you keep track using a seperate table to indicate current progress. Or right an action which takes the primary key as an argument, and prepare many actions using a script to update table rows one at a time by primary key.


2

I ran into this issue as well. The batch updating and is a good solution, but maybe slow if you only perform one batch per transaction. If your records are independent you can use a Flooding/Recursive approach which will run multiple batches per transaction. I described this in a similar question where I wanted to delete all entries of a large table. Check ...


2

The ONLYBILL1ST proposal has now been approved by 15 Block producers. I have tested and OnlyBillFirstAuthorizer is working now. I'm using eos-sharp. But it's very similar to eos-js. It's very simple. Just add the account you want to bill for the transaction first in the 'authorization'-part. //Add the private keys List<string> ...


1

There is no way to calculate this from within the action. The available CPU time is too complicated and depends on too many external variables. The actions are suposed to be determinsitic and repetable exactly as they ran in the first time so no external info which is dynamic is allowed in the dapp action code. You should optimize and test and design your ...


1

You are not charged for any RPC getter API calls. If you're not forced to sign the transaction, then there's no way to know which account to charge. You're charged if you're changing state or pushing data to the chain.


1

Find by primary key is an efficient operation and will scale with your table size. Looping over every row is not something you want to do in the smart contract in a direct way. The risk is you will hit the limit for a single transaction time. You can use demux to have a copy of the table data in an off chain table. Loop over the rows there and if you need ...


1

I think it makes sense to have more than one EOS account, exactly to deal with this case. In your "emergency" account, you have EOS that you are to use only for staking as needed. Either you can stake to yourself directly, or if this wouldn't be enough, you can buy a larger stake through Chintai, and delegate it to your main account.


1

You can now estimate your costs for a transaction by using EOS New York's EOS Charge. Methodology: We use a a MongoDB query that runs hourly and averages the CPU and NET resource costs experienced for every action performed on the EOS Mainnet within the previous 100,000 blocks (13.8 hours) across all Block Producers.


1

There is no tool as such but you can estimate the cost by looking at how are you storing the data (this will tell the estimation about RAM) and how much time does your action take (this will give you the idea about CPU). BTW, This video explains a lot about how to decide the cost estimation. If you get the time, go through the full video. HTH!


1

You can now estimate your costs for a transaction by using EOS New York's EOS Charge. Methodology: There is a MongoDB query that runs hourly. This query averages the CPU and NET resource costs experienced for every action performed on the EOS Mainnet within the last 100,000 blocks


1

In fungible tokens you track number of tokens per an account. In non-fungible tokens you track individual token per account. The latter is the only way to do non-fungible tokens - you need to track an individual token, as it would not be non-fungible otherwise. You cannot compress the memory cost beyond account:token id pair, so there is no way to reduce ...


1

In order to access this information, you must create a struct as follows: struct [[eosio::table, eosio::contract("eosio.system")]] user_resources { name owner; asset net_weight; asset cpu_weight; int64_t ram_bytes = 0; uint64_t primary_key()const { return owner.value; } // explicit ...


1

The failed transaction will not be attempted again automatically. If you're the dApp owner, you should increase the CPU resources or wait for them to replete and try again. Or better yet, redesign the dApp to make it more efficient if possible.


1

What you have written looks right to me. The reference for this is: https://developers.eos.io/eosio-cleos/v1.1.0/reference#cleos-system-delegatebw Something I noticed is that transferring EOS doesn't always work if you don't specify the correct precision. So you could also try delegating at the precision that the EOS supply was created with.


1

wait a few hours and send transaction again (it will work if you used CPU before in 24 hour window) stake more EOS for CPU and you can send again immediately. push to faster node where you transaction will execute below limit :) if it was slow node (low memory, swapping, other running processes on the server) and it was just a performance glitch, then ...


1

You're right, you can wait for the fastest BP, and also, you can vote out the BP which has slow CPU.


Only top voted, non community-wiki answers of a minimum length are eligible