Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 10 2017 22:42
    @jpitts banned @etherchamp1_twitter
  • Jun 05 2016 10:33
    @chriseth banned @adamskee
Kirsten Slater
@DrSlater06_twitter
@skiv71 im looking for a dapp dev
Neil Duffy
@skiv71
@DrSlater06_twitter really?
PM so we can discuss?
Luis Schliesske
@gitpusha
Hi @chriseth - just double-checking. receive() external payable virtual is not possible because a contract can have at most one receive function, right ?
matrixbot
@matrixbot
yassine Hello! I'm looking to develop a CDP smart contract where users stake ETH and get back a token. Anyone knows where I could find some examples I could follow? Thanks!
daniele999999
@daniele999999
any ideas on how to implement burns on solidity?
userli-li
@userli-li
hello guys,I would like to know how to implement HMAC in solidity, I can use the OpensSL to achieve HMAC in C.If I have to implement the HMAC algorithm on my own, with no other implemented code resources available for me to use in solidity?
userli-li
@userli-li
or other the encryption algorithm?
Lauri Peltonen
@microbecode
all stuff like encryption are typically very gas-expensive. you can try google; I just did and quick browsing only gave me this: https://goerli.etherscan.io/address/0xa16005f8f56eeb781d2d46f449db2e3d77a05ac2#code
stuff like encryption is quite useless, though, as everyone can see the key
userli-li
@userli-li
@microbecode thank you very much
ashBassili
@ashBassili

Newbie question: Having problems with solc.compile - compile script reads all contracts in a /contracts folder. Can get the source and packages up a json object as part of the setup to the compile input. But alas...I keep getting the following error from compiler:

{"errors":[{"component":"general","formattedMessage":"Unknown key \"errors\"","message":"Unknown key \"errors\"","severity":"error","type":"JSONError"}]}

QUESTION: Currently the input is an object containing contract source in text...comma separated. Should each contract source be an object?

Thank you in advance. Ash

Miles
@minton1
Question about gas costs: if I update a storage value with the value it already had stored, does that cost 5k gas or 0 gas? Is it therefore cheaper to check if the value is the same as the one already stored before writing or not?
Miles
@minton1

Did some tests on remix. I found that it costs less than 5k and more than 0 to write the same non-zero value to storage.

I also found that if you are modifying most of the values (ie, in a struct), it is cheaper to not check each value before writing the entire struct to storage, and if you are updating only some of the values it is cheaper to check before writing each struct value to storage.

David
@magus237

Hi,
Under Solidity 0.5, I could write such contract:

interface I {
    function f() external;
}

contract C {
    function f() external { /* do something useful */ }
}

contract D is I, C {
}

I.e. D would satisfy the interface I with C.
With Solidity 0.6 and above, I can no longer write this, because the compiler insists that I override f because it is inherited both from I and C, although there is only a single actual implementation of f (which is C.f).

Would it be possible for the compiler to allow the user to not override a function inherited multiple times when only one of
these functions has an implementation (i.e. has a body) ?

Daniel Kirchner
@ekpyron
There was a lot of discussion about which cases to allow there and which not to allow without being explicit when we overhauled inheritance in 0.6 - in this particular case the reasoning was that there is little assurance that C.f really is a semantically correct implementation of I.f (it could be an unrelated function that just happens to have the same name). The only way to be sure that C.f and I.f are actually meant to be "the same" function, is for f to occur in a common base interface. So ideally, if you can be sure that C.f actually implements I.f, then C should either inherit from I or from a common base interface of C and I. If there is such a common base interface, then the compiler does allow the case in which there is only one unique implementation in the base classes without overriding.
David
@magus237
Oh, I see. So in my simple example, if C inherits from I, then it works. Correct ?
Daniel Kirchner
@ekpyron
Yes!
David
@magus237
Great. Thanks !
guru260
@guru260
Is there any active mlm which uses token instead of ether? For example forsage uses ether. I need the same for ERC20 token.
David
@magus237

Actually, @ekpyron, I have an additional question.
How come this one is fine :

interface I { function f() external; }
interface J is I { function f() external override; }
contract C is J { function f() external override {} }
contract D is I, C { }

While this one is not ? (just swapping I and J in C and D's parents)

interface I { function f() external; }
interface J is I { function f() external override; }
contract C is I { function f() external override {} }
contract D is J, C { }
Daniel Kirchner
@ekpyron
That's a bit more tricky and one could probably argue about whether this should be allowed or not. The general principle is explained in some detail here https://docs.soliditylang.org/en/latest/contracts.html#function-overriding in particular in the paragraph More formally, it is not required to override a function.... The idea is that you traverse the inheritance graph backwards from the most derived contract and check if there is any ambiguity whatsoever (more detailed in the paragraph in the docs). In your example the main question is: why does J explicitly mention f? It would implicitly contain the f inherited from I even if it didn't mention it at all. So the reasoning is: since J mentions f explicitly, it is expected to impose some additional requirements on f beyond those of the f in I- and since C.f assures to implement I.f, but not J.f, you can't be sure that C.f satisfies the requirements of J.f. In the working example, this problem doesn't occur, since D inheriting from I just means it needs an I.f and since C indirectly implements I.f that requirement is clearly fulfilled. Does that make sense :-)?
Daniel Kirchner
@ekpyron

Note that

interface I { function f() external; }
interface J is I { }
contract C is I { function f() external override {} }
contract D is J, C { }

is practically the same as your second snippet, only that J doesn't explicitly mention f (indicating that it just needs a generic I.f and not some more specific version of f). So here it is again clear that C.f is a fine implementation of f in D, so this works without overriding.

David
@magus237
I see. That's clever.
Thanks for the detailed explanation.
Daniel Kirchner
@ekpyron

I see. That's clever.

That was at least our hope, yes :-).

David Roon
@adridadou
hey everyone, I know it's not necessarily the right place but I have no clue where else to go. I'm working with EIP-712 v4 and I have arrays as values to encode. Now on the javascript side, eth-sig-util does the job and it's all good, but I cannot find any example in solidity on how to do it
it seems like the encoding is similar to abi.encode(encoded version of each element) (which is not the same as encoding the array itself)
anyone has an idea how to do that properly ?
Benjamin Smith
@bh2smith

Dear solidity team:

Wanted to raise a strange compiler error we are seeing in solc-0.7.5

This is specifically dedicated to the following snippet:

    function simulateDelegatecallInternal(
        address targetContract,
        bytes memory calldataPayload
    ) public returns (bytes memory response) {
        (bool success, response) = targetContract.delegatecall(
            calldataPayload
        );
    }

The issue seems to occur when the return variable name is specified and we want to define it inside of a tuple where the other variable has not yet been declared. Here this is bool success.

The error we see is "Expected identifier but got ')'"

This can be worked around by defining success as a bool beforhand as follows:

    function simulateDelegatecallInternal(
        address targetContract,
        bytes memory calldataPayload
    ) public returns (bytes memory response) {
        bool success;
        (success, response) = targetContract.delegatecall(
            calldataPayload
        );
    }

but seems a bit unnecessary. Wondering if I should file this as a bug, but thought I'd reach out here first...

Misaka Mikoto 10001
@mikoto10001
Hi, Is it possible to remap relative path like ../ to another path to compile contracts using solc like solc "../"=anypath/in/system/ file.sol?
chriseth
@chriseth
@bh2smith it is unfortunate, but you cannot mix variable declarations with assignments to existing variables
@mikoto10001 the part left of = is considered to be an absolute path inside the compiler's virtual file system
importing from ../ is considered bad practice exactly because it does not mix well with these remappings
instead, inside a file myproject/library/x.sol you should import e.g. import myproject/otherCode/y.sol
Misaka Mikoto 10001
@mikoto10001
Got it, and is there any way to verify a contract code if it use "../" in import path?Am I have to rebuild the same file tree to get the contract compiled. Btw, I can use solc =/path/m file.sol to do this when the empty remapping is allowed before. But it removed currently.
chriseth
@chriseth
if you use standard-json, you can "rename" all the files you need
which "artefacts" do you have? Do you have the metadata.json file?
Misaka Mikoto 10001
@mikoto10001
I have all source files.
chriseth
@chriseth
but your path layout is different?
Misaka Mikoto 10001
@mikoto10001
Yes, It contains serval relative path using "../"
chriseth
@chriseth
you can also try to use --base-path, but this is currently a little buggy, unfortunately
so as I said, if you use standard-json, then it is a bit more work, but you have full control over the paths
Misaka Mikoto 10001
@mikoto10001
I want to make this automatic as a service.
Benjamin Smith
@bh2smith
Thanks @chriseth! I will pass this along.
David Starke
@dstarke

@adridadou For an array of atomic values, you can calculate the hash of an array value with:

keccak256(abi.encodePacked(array))

For arrays of structs, you have to calculate the hashes of the struct elements first:

bytes32[] memory structHashes = new bytes32[](array.length);
for (uint256 i; i <array.length; i++){
    structHashes[i] = hash(array[i]);
}

where hash() computes the EIP712 struct hash of the array element. You then treat the hash array just like an atomic array:

keccak256(abi.encodePacked(structHashes))

There are some examples of doing this in this contract

chriseth
@chriseth
@mikoto10001 what exactly do you wnat to make automatic?
Misaka Mikoto 10001
@mikoto10001
I want to build a service to verify contracts like verify contract in etherscan
These contracts are uploaded separately, but can compiled together to verify the contract deployed code is fitted or not.