18

Inline actions sent by a contract are executed with a virtual "signature" that satisfies the contract@code permission where contract is the account where the code is installed. Your inline action declares the permission rider@active however, contract@code does not satisfy rider@active by default. In order to prevent nefarious contracts from doing "bad ...


15

When declaring a multi_index to use as a table a contract (eg. contracta) you would typically create a struct and typedef similar to this: // @abi table myobjects struct myobject { name sender; // ... other properties here EOSLIB_SERIALIZE(myobject, (sender)(...)) } typedef multi_index<N(myobjects), myobject> myobjects_t; and then create ...


14

UPDATE: This is the code I used to experiment with all combinations of permissions I could come up with: https://github.com/andresberrios/permissions_test After a lot of experimentation, I finally understand how permissions work in EOSIO! EOS Permission Model - Overview An account can have various permissions (like owner and active), which are represented ...


13

Update 19th September: As of v1.3.0, it is now possible to delete the smart contract from an account using the --clear flag ($ cleos set contract <account> --clear) To make a small contract, I suggest not using cpp or eosiocpp/eosio-cpp at all. The smallest contract I managed to upload on chain takes 0.392 KiB and it's written in webassembly: ...


11

eosiocpp currently compiles contracts using c++14. cib compiles contracts using the c++17 language, but c++14 library. sandboxing: contracts are compiled to WASM. Normal OS functions (filesystem, threading, etc.) are not available. Note: cib requires an up-to-date Firefox (fastest) or Chrome (slow loading).


11

Think of it as sending a carbon copy of the action. Since eosio.token does it with transfer, contracts can monitor and respond to deposits. e.g. if user a transfers EOS to contract b, then b could automatically transfer another token type back to a, creating a simple exchange.


11

/libraries/chain/include/eosio/chain/config.hpp defines setcode_ram_bytes_multiplier to 10x the number of bytes of the compiled WASM. This covers the overhead of the VM and other memory. This is the base amount just for the code. From here there are other constants you can review: overhead_per_row_pper_index_ram_bytes = 32 + sizeof(key) + row data for ...


10

So, for this scenario we can create another index that concatenates both indexes and look for it. As an example, let's see a scenario where we can invite accounts to a group and each invitation has an id. // table declaration for invites // @abi table invitation i64 struct invitation { uint64_t id; uint64_t group; account_name user; ...


10

I found it in Dawn 4.0 release, it's simply is_account(account_name) Check out the eosio.token new contract in transfer action, release: https://github.com/EOSIO/eos/blob/dawn-v4.0.0/contracts/eosio.token/eosio.token.cpp#L76 eosio_assert( is_account( to ), "to account does not exist");


9

Action names, table names, index names, account names, and everything else you use N(foo), "foo"_n, or eosio::name("foo") for, have these rules. A contract belongs to an account. 12 characters max May contain: a-z, 1-5, or . May not end with . Names are encoded in base-32: . = 0 1-5 = 1 - 5 a-z = 6 - 31 The 5 MSBs of the uint64 contain the first ...


9

The _self auth, shown here require_auth( _self ); requires the authority of the owner of the contract, in this case eosio. If we inspect that account with get account we see this owner 1: 1 eosio.prods@active Which means eosio has given his authority to eosio.prods. And if we inspect that account we see this. active 15: 1 argentinaeos@...


9

Some further explanation of how the value to pass via cleos was derived. As already mentioned in the original post, this all revolves around endianness. For some reason the checksum256 value is returned in a different endian to what the index key type bounds for sha256 expects. If you have the below hash (checksum256) returned by a row in the table: ...


8

the producers all agree "offline" and then sign a multi-sig message setting the current max block size and total available RAM.


8

Declare the following struct in your contract struct account { asset balance; uint64_t primary_key()const { return balance.symbol.name(); } }; typedef eosio::multi_index<N(accounts), account> accounts; Write the following in one of the action of contract. It is reading the accounts table of eosio.token contract and printing ...


8

Until eosio.cdt v1.6 You could use: eosio::current_time() now() From eosio.cdt v1.6 onwards You have to #include <eosio/system.hpp> and then you can use: eosio::current_time_point eosio::current_block_time


7

Yes, it can be found on the Developers Portal here. Deprecated EOSIO GitHub wiki


7

EDIT: The new version (dawn-v4.0.0) improved the permissions system which totally makes sense. If you want to do a eosio.token::transfer from your contract you need to add a specific permission for that. Check this: https://github.com/EOSIO/eos/issues/3013 As Dan said you need to add a permission like this: cleos set account permission your_account ...


7

How would users best ensure that the owner of the token didn't cheat and issue themselves additional tokens across a bunch of new accounts? This isn't really an issue, it's assumed by all involved in an airdrop that the creator isn't doing this out of benevolence. They need not cheat the system with a 'bunch of new accounts', that's a lot of unnecessary ...


7

Try the below snippet: // @abi table tests i64 struct test_rec { test_hash hash; account_name creator; uint64_t primary_key() const { return hash; } account_name get_creator() const { return creator; } }; typedef eosio::multi_index<N(tests), test_rec > tests;


7

There are two separate concepts: the blockchain and the database. The blockchain is an immutable log of transactions, e.g. transfer 5.0000 EOS from usera to userb. The database holds mutable state information, e.g. userb has 10.0000 EOS. Contracts modify the database in response to actions. Even though the database is mutable, you can recreate it at any ...


7

Use the name struct. 'name' is defined in types.hpp. For example, if you have the variable user of type account_name, you can print the user as follows: auto n = name{user}; print("Hello, ", n); std::string str = n.to_string();


7

The following code is in the link below. https://bitcoin.stackexchange.com/questions/76480/encode-decode-base-58-c The important thing is that the first three characters (EOS) in the public key are prefix, so you can truncate it. EOS8KgkQikWK84J2jJ1Nvd3ttfJNRicYZsdbunbe9biR99dHGb24a => 8KgkQikWK84J2jJ1Nvd3ttfJNRicYZsdbunbe9biR99dHGb24a #include <...


7

Have a look to available_primary_key in the EOS documentation, multi indexes do support auto increment keys.


7

Contracts inherit from eosio::contract, and, if we look in eosiolib/contract.hpp for the base class, we see that the constructor for eosio::contract is as follows: contract( account_name n ):_self(n){} Therefore, the account that creates the contract and calls the constructor becomes _self. Thus, require_auth(_self) ensures that the account executing the ...


7

You can not forbid reading the data from a smart contracts table, because it is exposed by the RPC interface or CLI. What you can do to prevent understanding it by 3rd parties, is encrypt your data like @confused00 said. If you just want to limit access for adding, modyfing or deleting, you can use the scopes of the multi_index and the require_auth method, ...


6

Via the Developers Portal When adding a entry... orders.emplace( payer, [&]( auto& o ) { o.id = 1; o.expiration = 300; o.owner = N(dan); }); The first parameter payer is the account who pays the bill. When modifying an entry... orders.modify( order2, payer, [&]( auto& o ) { o.expiration = 400; }); Payer is the second argument, ...


6

Yes, there's a big integer library for EOS.IO made by PlayerOne.


6

When a record is created, the user specified in the emplace call will be charged for the RAM usage. A subsequent modify call on that record will specify a user (possibly different) that will be charged. That user will incur the storage cost of the entire row, and the original user (if different) will have their RAM returned to them for use elsewhere. When ...


6

Yes, I believe that your understanding is correct, as confirmed in a discussion on Telegram Developers Channel pasted below--Todd Fleming is a contributor to EOSIO codebase: 16th of August User: is there any way for an user to remove RAM allocated that they own ? let’s say that I own a malicious contract that once an action hit, check ram of user, and ...


6

EOS is using a WebAssembly virtual machine to run smart contracts. By theory you can use any language that will compile into WASM, but the most approved way is to use the C++ library and the eosiocpp tool (EDIT this will soon be replaced by the eosio-cpp tool). Please have a look at the official developer portal. I would also recommend to use the Docker ...


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