Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    chriseth
    @chriseth
    Do we know how ofter we download compiler binaries? We do cache them nowadays, do we?
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> On server docker containers have direct access to binaries
    <Edi | Shard Labs> only thing we do is git pull periodically
    <Edi | Shard Labs> I can take a look specifically how much downloading we have if you want
    chriseth
    @chriseth
    so we don't fetch it from binaries.soliditylang.org but from github?
    then it's fine :)
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> yeah
    <Edi | Shard Labs> even if binary doesn't exist we donwload it and then cache it
    <Edi | Shard Labs> so it's a non issue
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <ligi> btw. the solc binaries are also on ipfs of komputing
    <ligi> there is this update script running that pulls from gh and adds to ipfs
    chriseth
    @chriseth
    I saw that the ui v3 pr as merged - can we have a demo in the meeting?
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <fabijan_shardlabs> it is merged only on our staging server, and exists in parallel with the old ui; also it is still not publicly exposed - this is something to be discussed today
    <fabijan_shardlabs> but we can have a demo in the meeting, yes
    chriseth
    @chriseth
    ah ok!
    FabijanC
    @FabijanC

    @chriseth Regarding yesterday's conclusion about storing constructor arguments for all contracts and not just for those using immutables, here are some thoughts:

    • Contracts using immutables are verified relying on retrieved creation data, regardless of storing their constructor arguments
    • The current implementation of retrieving the creation data relies on the already described binary search, which can take up to 10 seconds
    • Contracts without immutables are often verified within a second
    • Even if the latter contracts use a constructor for initialization, the initialized variables may later be changed since non are immutable

    With the current implementation, we would sacrifice user experience in order to store constructor arguments for every contract - and the values used for initialization might later be overwritten. So, at least for now, should we just keep the storing of constructor arguments only for contracts that use immutables?

    chriseth
    @chriseth
    as long as we do not verify creation bytecode, the verification is not perfect
    you could just replace the constructor code by something else
    so we have to verify constructor code for all contracts
    that's why the creation code db is so important
    I think we decided yesterday that as long as we do not have the db, it is fine to compare creation code (and thus also only store constructor arguments) for contracts that have immutables
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <fabijan_shardlabs> ok!
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <ligi> we can get rid of all non sourcify domains right?
    <ligi> there are still some verification-komputing URLs from pre sourcify renaming
    <ligi> can I delete them?
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> You mean in apache config?
    <Edi | Shard Labs> Like something.shardlabs?
    Santiago Palladino
    @spalladino
    Hey, I'm seeing certificate issues with https://contractrepo.komputing.org/. Is this related to the renaming mentioned above? If so, what would be the new URL?
    (also, apologies if this is not the right place to bring this up!)
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> Tnx for letting us know, it's the correct place
    <Edi | Shard Labs> looking at it
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> @ligi added draft.staging.sourcify.dev to dns, I don't have komputing dns record access
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <ligi> draft is up
    <ligi> also now
    <ligi> yea - asking regarding komputing if I can delete them
    <ligi> cleanup a bit
    <Edi | Shard Labs> I think some people like spalladino are using it for integration with tools so let's keep it for now so we don't break access.
    <Edi | Shard Labs> Should communicate first with the teams that have integrated sourcify not to break their integrations
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <ligi> we need a plan/way to phase this out
    <ligi> getting messy
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> agreed, let's talk about it in more detail on next meeting as we have to coordinate with teams using sourcify
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <franzihei> yes I think it would make most sense to use the sourcify.dev domain for all "official" stuff
    <Edi | Shard Labs> agreed
    <franzihei> and then people can still run it on their own / build their own stuff etc eventually if they like to
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <ligi> @Edi | Shard Labs did you check the geth on gather?
    <ligi> still do not see that process running
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> On it
    Alex Beregszaszi
    @axic

    Just dropping this here: https://github.com/tintinweb/smart-contract-sanctuary

    A home for ethereum smart contracts verified on Etherscan.
    Note: This repo is updated twice a day.

    I know that due to uncertainty about licensing it may not make sense importing it into sourcify, but still.

    But apparently etherscan has an API for it now (used by that repo): https://etherscan.io/exportData?type=open-source-contract-codes
    Eth-Gitter-Bridge
    @Eth-Gitter-Bridge
    <Edi | Shard Labs> Nice, I like the format of the repo