ethereum

ethereum

Member Since 8 years ago

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
265
repos
Activity
Jan
19
11 hours ago
started
started time in 4 minutes ago
Activity icon
issue

Aniket-Engg issue ethereum/remix-project

Aniket-Engg
Aniket-Engg

issue with url params in compiler

If value for evmVersion is given as something non-existing in URL params, on UI it sets compiler default as evm version but shows error on compilation Screenshot 2022-01-19 at 4 29 22 PM

started
started time in 6 minutes ago
started
started time in 13 minutes ago
Activity icon
issue

Aniket-Engg issue ethereum/remix-project

Aniket-Engg
Aniket-Engg

AST node highlight in editor issues

  • Moving to node definition reference using up-down carrots is not appropriate
Screenshot 2022-01-19 at 4 11 45 PM
  • Even on file change it shows old node type references
Screenshot 2022-01-19 at 4 12 50 PM
started
started time in 18 minutes ago
open pull request

fjl wants to merge ethereum/go-ethereum

fjl
fjl

rlp/rlpgen: RLP encoder code generator

This is a new tool to generate EncodeRLP (and DecodeRLP) method implementations from a struct definition.

I have applied this tool to several types in core/types, and here are the benchmark results:

name                             old time/op    new time/op    delta
EncodeRLP/legacy-header-8           328ns ± 0%     237ns ± 1%   -27.63%  (p=0.000 n=8+8)
EncodeRLP/london-header-8           353ns ± 0%     247ns ± 1%   -30.06%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8     237ns ± 0%     123ns ± 0%   -47.86%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8            297ns ± 0%     301ns ± 1%    +1.39%  (p=0.000 n=8+8)

name                             old speed      new speed      delta
EncodeRLP/legacy-header-8        1.66GB/s ± 0%  2.29GB/s ± 1%   +38.19%  (p=0.000 n=8+8)
EncodeRLP/london-header-8        1.55GB/s ± 0%  2.22GB/s ± 1%   +42.99%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8  38.0MB/s ± 0%  64.8MB/s ± 0%   +70.48%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8          910MB/s ± 0%   897MB/s ± 1%    -1.37%  (p=0.000 n=8+8)

name                             old alloc/op   new alloc/op   delta
EncodeRLP/legacy-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/london-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/receipt-for-storage-8     64.0B ± 0%      0.0B       -100.00%  (p=0.000 n=8+8)
EncodeRLP/receipt-full-8             320B ± 0%      320B ± 0%      ~     (all equal)
fjl
fjl

Yes, it's unreachable in this case. The double checking happens because BaseFee is optional. If there was another optional field, the check would make sense.

pull request

fjl merge to ethereum/go-ethereum

fjl
fjl

rlp/rlpgen: RLP encoder code generator

This is a new tool to generate EncodeRLP (and DecodeRLP) method implementations from a struct definition.

I have applied this tool to several types in core/types, and here are the benchmark results:

name                             old time/op    new time/op    delta
EncodeRLP/legacy-header-8           328ns ± 0%     237ns ± 1%   -27.63%  (p=0.000 n=8+8)
EncodeRLP/london-header-8           353ns ± 0%     247ns ± 1%   -30.06%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8     237ns ± 0%     123ns ± 0%   -47.86%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8            297ns ± 0%     301ns ± 1%    +1.39%  (p=0.000 n=8+8)

name                             old speed      new speed      delta
EncodeRLP/legacy-header-8        1.66GB/s ± 0%  2.29GB/s ± 1%   +38.19%  (p=0.000 n=8+8)
EncodeRLP/london-header-8        1.55GB/s ± 0%  2.22GB/s ± 1%   +42.99%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8  38.0MB/s ± 0%  64.8MB/s ± 0%   +70.48%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8          910MB/s ± 0%   897MB/s ± 1%    -1.37%  (p=0.000 n=8+8)

name                             old alloc/op   new alloc/op   delta
EncodeRLP/legacy-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/london-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/receipt-for-storage-8     64.0B ± 0%      0.0B       -100.00%  (p=0.000 n=8+8)
EncodeRLP/receipt-full-8             320B ± 0%      320B ± 0%      ~     (all equal)
open pull request

holiman wants to merge ethereum/go-ethereum

holiman
holiman

rlp/rlpgen: RLP encoder code generator

This is a new tool to generate EncodeRLP (and DecodeRLP) method implementations from a struct definition.

I have applied this tool to several types in core/types, and here are the benchmark results:

name                             old time/op    new time/op    delta
EncodeRLP/legacy-header-8           328ns ± 0%     237ns ± 1%   -27.63%  (p=0.000 n=8+8)
EncodeRLP/london-header-8           353ns ± 0%     247ns ± 1%   -30.06%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8     237ns ± 0%     123ns ± 0%   -47.86%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8            297ns ± 0%     301ns ± 1%    +1.39%  (p=0.000 n=8+8)

name                             old speed      new speed      delta
EncodeRLP/legacy-header-8        1.66GB/s ± 0%  2.29GB/s ± 1%   +38.19%  (p=0.000 n=8+8)
EncodeRLP/london-header-8        1.55GB/s ± 0%  2.22GB/s ± 1%   +42.99%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8  38.0MB/s ± 0%  64.8MB/s ± 0%   +70.48%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8          910MB/s ± 0%   897MB/s ± 1%    -1.37%  (p=0.000 n=8+8)

name                             old alloc/op   new alloc/op   delta
EncodeRLP/legacy-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/london-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/receipt-for-storage-8     64.0B ± 0%      0.0B       -100.00%  (p=0.000 n=8+8)
EncodeRLP/receipt-full-8             320B ± 0%      320B ± 0%      ~     (all equal)
holiman
holiman

This looks like it's unreachable code. Known quirk? Not that it matters a whole lot, if it makes the encoder logic simpler.

pull request

holiman merge to ethereum/go-ethereum

holiman
holiman

rlp/rlpgen: RLP encoder code generator

This is a new tool to generate EncodeRLP (and DecodeRLP) method implementations from a struct definition.

I have applied this tool to several types in core/types, and here are the benchmark results:

name                             old time/op    new time/op    delta
EncodeRLP/legacy-header-8           328ns ± 0%     237ns ± 1%   -27.63%  (p=0.000 n=8+8)
EncodeRLP/london-header-8           353ns ± 0%     247ns ± 1%   -30.06%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8     237ns ± 0%     123ns ± 0%   -47.86%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8            297ns ± 0%     301ns ± 1%    +1.39%  (p=0.000 n=8+8)

name                             old speed      new speed      delta
EncodeRLP/legacy-header-8        1.66GB/s ± 0%  2.29GB/s ± 1%   +38.19%  (p=0.000 n=8+8)
EncodeRLP/london-header-8        1.55GB/s ± 0%  2.22GB/s ± 1%   +42.99%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8  38.0MB/s ± 0%  64.8MB/s ± 0%   +70.48%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8          910MB/s ± 0%   897MB/s ± 1%    -1.37%  (p=0.000 n=8+8)

name                             old alloc/op   new alloc/op   delta
EncodeRLP/legacy-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/london-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/receipt-for-storage-8     64.0B ± 0%      0.0B       -100.00%  (p=0.000 n=8+8)
EncodeRLP/receipt-full-8             320B ± 0%      320B ± 0%      ~     (all equal)
pull request

holiman merge to ethereum/go-ethereum

holiman
holiman

rlp/rlpgen: RLP encoder code generator

This is a new tool to generate EncodeRLP (and DecodeRLP) method implementations from a struct definition.

I have applied this tool to several types in core/types, and here are the benchmark results:

name                             old time/op    new time/op    delta
EncodeRLP/legacy-header-8           328ns ± 0%     237ns ± 1%   -27.63%  (p=0.000 n=8+8)
EncodeRLP/london-header-8           353ns ± 0%     247ns ± 1%   -30.06%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8     237ns ± 0%     123ns ± 0%   -47.86%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8            297ns ± 0%     301ns ± 1%    +1.39%  (p=0.000 n=8+8)

name                             old speed      new speed      delta
EncodeRLP/legacy-header-8        1.66GB/s ± 0%  2.29GB/s ± 1%   +38.19%  (p=0.000 n=8+8)
EncodeRLP/london-header-8        1.55GB/s ± 0%  2.22GB/s ± 1%   +42.99%  (p=0.000 n=8+8)
EncodeRLP/receipt-for-storage-8  38.0MB/s ± 0%  64.8MB/s ± 0%   +70.48%  (p=0.000 n=8+7)
EncodeRLP/receipt-full-8          910MB/s ± 0%   897MB/s ± 1%    -1.37%  (p=0.000 n=8+8)

name                             old alloc/op   new alloc/op   delta
EncodeRLP/legacy-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/london-header-8           0.00B          0.00B           ~     (all equal)
EncodeRLP/receipt-for-storage-8     64.0B ± 0%      0.0B       -100.00%  (p=0.000 n=8+8)
EncodeRLP/receipt-full-8             320B ± 0%      320B ± 0%      ~     (all equal)
started
started time in 33 minutes ago
Activity icon
fork

windwht forked ethereum/remix-live

⚡ Live deployment of the remix IDE
windwht Updated
fork time in 35 minutes ago
started
started time in 37 minutes ago
Activity icon
fork

cpk777 forked ethereum/go-ethereum

⚡ Official Go implementation of the Ethereum protocol
cpk777 GNU Lesser General Public License v3.0 Updated
fork time in 46 minutes ago
push

ekpyron push ethereum/solidity

ekpyron
ekpyron

Equality operator allowed for external function types

ekpyron
ekpyron

Merge pull request #12470 from nishant-sachdeva/equality_operator_for_external_functions

Equality operator allowed for external function types

commit sha: ecd8b9778b1096c7971c55b308b48332b718a225

push time in 46 minutes ago
pull request

ekpyron pull request ethereum/solidity

ekpyron
ekpyron

Equality operator allowed for external function types

Closes #12411

Activity icon
issue

ekpyron issue ethereum/solidity

ekpyron
ekpyron

Equality operator for external functions

Abstract

Currently the equality operator only works with internal function types. It should be allowed also for external function types.

Motivation

The way you compare function pointers today is not intuitive. For external ones you can only compare serialized values (e.g. keccak256(abi.encodePacked(f))) and using == and != is disallowed. For internal ones the opposite is true. It would be much more intuitive to have one method that works uniformly with both.

The main reasons not to allow easy comparison with == for some types are that (1) it could potentially hide a very costly operation (e.g. when comparing arrays) or (2) it would be ambiguous (e.g. shallow comparison of references vs deep comparison of content). I think that none of these applies here. External function pointers have fixed size and the address+selector combination is enough to uniquely identify an external function without ambiguity.

Serialization also makes the comparison unnecessarily costly. The keccak256() + abi.encode() combination allocates memory and this allocation has been notoriously hard to optimize out so far (#12335).

Example of current behavior

contract C {
    function () external externalStorage;

    function comparePtr() public {
        function () external externalLocal1;
        function () external externalLocal2;

        externalLocal1 == externalLocal2;
        externalLocal1 != externalLocal2;

        externalLocal1 == externalStorage;
        externalStorage != externalLocal2;
    }
}
Error: Operator == not compatible with types function () external and function () external
 --> test.sol:8:9:
  |
8 |         externalLocal1 == externalLocal2;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error: Operator != not compatible with types function () external and function () external
 --> test.sol:9:9:
  |
9 |         externalLocal1 != externalLocal2;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error: Operator == not compatible with types function () external and function () external
  --> test.sol:11:9:
   |
11 |         externalLocal1 == externalStorage;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error: Operator != not compatible with types function () external and function () external
  --> test.sol:12:9:
   |
12 |         externalStorage != externalLocal2;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Specification

f == g and f != g should not cause a compilation error if f and g are external functions (or variables of an external function type) with the same signature. The comparison should always return false if they belong to different contracts. If should return true if and only if both the address and the selector are identical.

Backwards Compatibility

The change is fully backwards-compatible because such comparisons are currently disallowed and result in a compiler error.

open pull request

asn-d6 wants to merge ethereum/consensus-specs

asn-d6
asn-d6

Hmm. IntermediateBlockBidWithRecipientAddress.intermediate_block_bid is also a Union but is not treated as such here and in the else clause.

Activity icon
issue

fjl issue comment ethereum/go-ethereum

fjl
fjl

Chore: use same receiver names

Using same receiver name will be greater than using different name.

fjl
fjl

If you rename the receiver, you must also apply this renaming in the method body.

Activity icon
issue

obbap1 issue comment ethereum/go-ethereum

obbap1
obbap1

Chore: fix possible context collisions in the HTTP request

Activity icon
fork

lkn4wrk forked ethereum/btcrelay

⚡ Ethereum contract for Bitcoin SPV: Live on https://etherscan.io/address/0x41f274c0023f83391de4e0733c609df5a124c3d4
lkn4wrk MIT License Updated
fork time in 1 hour ago
Activity icon
fork

Pooja0509 forked ethereum/EIPs

⚡ The Ethereum Improvement Proposal repository
Pooja0509 Updated
fork time in 1 hour ago
Activity icon
issue

fjl issue comment ethereum/go-ethereum

fjl
fjl

Chore: fix possible context collisions in the HTTP request

fjl
fjl

Thanks for the notice! These keys are used by cmd/clef, so we cannot just rename them. But I have a patch somewhere to expose this info in a structured way, will submit that.

started
started time in 1 hour ago
Activity icon
issue

eth-bot issue comment ethereum/EIPs

eth-bot
eth-bot

docs: fix a typo in eip-1052.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
eth-bot
eth-bot

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):


(fail) eip-1052.md

classification
updateEIP
  • eip-1052.md is in state final at the head commit, not draft or last call or review; an EIP editor needs to approve this change
  • This PR requires review from one of [@micahzoltu, @lightclient, @axic, @gcolvin]
  • eip-1052.md requires approval from one of (@arachnid)
Activity icon
issue

github-actions[bot] issue comment ethereum/EIPs

github-actions[bot]
github-actions[bot]

docs: fix a typo in eip-1052.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
github-actions[bot]
github-actions[bot]

We kindly remind you to check out EIP-1 for guidance. If this issue was created as a “discussions-to” for an EIP or to discuss an idea for an EIP, please close it and create a thread at Fellowship of Ethereum Magicians.

pull request

fishmandev pull request ethereum/EIPs

fishmandev
fishmandev

docs: fix a typo in eip-1052.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
Previous