Skip to content
This repository has been archived by the owner on Jul 13, 2023. It is now read-only.

Soliditylangorg domain explainer post #136

Merged
merged 1 commit into from
May 3, 2021
Merged

Conversation

franzihei
Copy link
Member

No description provided.

_posts/2021-04-30-soliditylangorg-umbrella-domain.md Outdated Show resolved Hide resolved
_posts/2021-04-30-soliditylangorg-umbrella-domain.md Outdated Show resolved Hide resolved
_posts/2021-04-30-soliditylangorg-umbrella-domain.md Outdated Show resolved Hide resolved
_posts/2021-04-30-soliditylangorg-umbrella-domain.md Outdated Show resolved Hide resolved

The ``github.io`` hosting has a 10 GB size limit and we exceeded it so we had to switch to a different one. For people who were using the ``ethereum.org`` domain the transition should have been seamless but there was nothing we could do about ``github.io`` and we had to just deprecate it.

We left it up but it hosts binaries only up to 0.7.2 and does not have the native binaries.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just checked to make sure and looks like it has 0.7.2 nightlies but does not have the 0.7.2 release itself. Do you think it's worth clarifying, given that it's deprecated anyway?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's needed.

## Blog

The Solidity blog was originally available at ``solidity.ethereum.org``. Now, the blog is at home at [blog.soliditylang.org](https://blog.soliditylang.org/) and similarly to how it is handled with the docs, the transition should have felt seamless to users. All old links still work and redirect to the corresponding equivalent on the new domain.
## Static Binaries / Solc-Bin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also describe the situation with binaries and rebuilds here? It goes more or less like this:

  • Originally solc-bin contained only platform-independent emscripten binaries that run via solc-js. For example Remix IDE uses them to compile code in the browser. These were asm.js binaries, which means it's just JavaScript and not very fast.
  • Around 0.6.2 we started building emscripten binaries as wasm. They're faster and for that reason @ekpyron rebuilt older binaries in solc-bin to wasm.
  • Somewhere in the 0.7.x release cycle people requested adding native binaries to solc-bin as well (Adding solc binaries to solc-bin solidity#9226). I gathered them from the release pages and added them to solc-bin. I also reorganized the directory structure a bit.
  • This did not include macOS native builds for many versions because we only started doing them in 0.6.9. So I did builds for older versions (down to 0.3.6) and added them to solc-bin.
  • Around the same time I also replaced Emscripten 0.4.15, 0.5.9, 0.5.11 in solc-bin with versions from the release page because they were different (Alternative versions of 0.4.15, 0.5.9, 0.5.11 from github release page solc-bin#57).
  • Late last year we discovered that macOS binaries for 0.3.6-0.6.0 do not produce identical bytecode as the others which hinders verification (Solidity 0.5.17 installed with Homebrew produces a different output than the version downloaded from solc-bin.ethereum.org solidity#10183). The bytecode they produce is valid but they have a slightly different version string which makes the metadata hash included in the bytecode different.
  • I have rebuilt the macOS binaries and replaced the ones that were already in solc-bin (macOS binaries with correct version strings solc-bin#76).
    • As a result checksums on the file list changed. Anyone using the old list to verify the binaries would get an errror trying to verify it against the new binaries.
      • Our policy is to avoid removing or modifying files already added to solc-bin but we have decided that leaving faulty ones there would cause more harm than good.
    • Many tools cache the list and do not redownload it if it's already available. That's for example what Hardhat used to do and it caused hard to understand breakage for people using it. As a result they decided to work around it by redownloading the list when the hash does not match (Smaller downloader fix NomicFoundation/hardhat#1392).
      • The fix PR also included a change from solc-bin.ethereum.org to binaries.soliditylang.org. The change was fine but not really necessary to fix the issue. It, however, made people think that the domain was the cause of the breakage.
  • As a part of macOS rebuilds I made an effort to actually verify that release binaries for the same version actually do produce the same bytecode on all platforms.

This is probably way too detailed to post as a whole but we could at least mention something about the problem with checksums.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the overall structure/content of this post, I think it would make sense posting this as a separate follow up one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, if we want to describe it all in detail. But do we?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is an important thing worth its own post. Even if it is three paragraphs only it is worth it given compiler binaries were replaced. That is serious.

But even describing the asm.js and wasm binaries (what are the differences, when we started with which, etc.) can be quite some detail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I'm fine with it either way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're faster and for that reason @ekpyron rebuilt older binaries in solc-bin to wasm.

The reason was rather that browsers decreased the available javascript stack size, which caused the old builds to break by the way. If the wasm builds are actually noticable faster, then that's secondary to actually working :-).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok maybe this topic should get its own short post then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason was rather that browsers decreased the available javascript stack size, which caused the old builds to break by the way.

Interesting detail. That would explain why Remix is properly using wasm builds when available but some other projects that I've seen don't care and just to straight to bin/.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case you're interested: before moving to wasm builds we had interesting workarounds like this: ethereum/solidity#6595 and that https://github.com/ethereum/solidity/pull/6595/files, since we figured out the part triggering the stack issues. Interestingly it wasn't only once but several times that browsers decreased those limits :-). But we didn't want to just backport those fixes and we weren't sure if and when it'd break again - moving to wasm and rebuilding all old versions was mainly a solution to that entire mess.

_posts/2021-04-30-soliditylangorg-umbrella-domain.md Outdated Show resolved Hide resolved
_posts/2021-04-30-soliditylangorg-umbrella-domain.md Outdated Show resolved Hide resolved
@chriseth
Copy link
Contributor

chriseth commented May 3, 2021

circleci should be fixed

@franzihei franzihei merged commit 1d20703 into master May 3, 2021
@franzihei franzihei deleted the soliditylangorg-domain branch May 3, 2021 15:28
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants