ethereum / solidity-blog Goto Github PK

• 2016-06-10-smart-contract-security #53
• 2016-09-01-formal-methods-roadmap
• 2016-11-01-security-alert-solidity-variables-can-overwritten-storage
• 2017-05-03-solidity-optimizer-bug.md #52

Write a blog post about upcoming changes and new features in 0.8, to go live with the preview release.

I think this could be useful, i.e. *This post was originally posted on [blog.ethereum.org](link here).* below the title.

We want to write a blog post about the new inheritance system. It will be part of the Solidity 0.6.x features series.

Workflow

• @elenadimitrova draft post on HackMD
• @chriseth (technical) accuracy review on HackMD
• @franzihei style/content review on HackMD
• create PR in this repo
• final review
• merge PR / publish blog post

Deadline

This post should be published until XX/XX/XXXX.

Link to draft post on HackMD

We want to update the community more regularly about what we're working on. As part of this effort, let's write about what's the lastest news / interesting stuff happening in SMTChecker land. :)

We want to write a blog post outlining the memory creation overflow bug, which has been reported on March 28th.

Workflow

• @ekpyron to draft post
• @chriseth (technical) accuracy review
• @franzihei style/content review
• merge PR / publish blog post once v0.6.5 is released

Deadline

This post should be published alongside with the next Solidity release (v0.6.5), presumably Monday, 6th of April.

Link to draft post

#13

From ethereum/solidity#8735 (comment):

Concerning stability of the URLs: Maybe the blog posts should be under solidity.ethereum.org/blog/date/post

I guess here @chriseth anticipates we move the blog to a different URL.

However I think it would be possible to leave as-is and add a redirect to solidity.tld/blog/... once we have a new domain with a landing page and more than a blog.

I think if we were to do this, it should contain the short intro from the release page (and perhaps the changelog) and the link to the release. But I wouldn't copy paste the entire release page with all the different links.

Any opinions?

Also not suggesting we should do this retroactively for every release, but we may as well if it can be automated. Probably there is a github API to download the release text.

Solidity 0.1.0 will be 5 years on the 10th of July.

Perhaps it is worth commemorating this with some retrospect how the project, team, language, and ecosystem has changed over time?

May be combined with #69.

@chriseth @franzihei opinion?

Potentially copy over these too:

• https://blog.ethereum.org/2016/11/09/analysis-storage-corruption-bug/ (this was a response to https://blog.ethereum.org/2016/11/01/security-alert-solidity-variables-can-overwritten-storage/)
• https://blog.ethereum.org/2016/03/30/solidity-available-in-visual-studio/

See https://github.com/axic/eth2.0-deposit-contract

The categories I suggest (or the plural form of these):

• Release
• Tutorial
• Update / Announcement

@franzihei @chriseth What do you think?

This could especially make sense if we do #31 to aid search-ability.

There has been a security advisory published by Github to update Kramdown due to a vulnerability found: https://github.com/ethereum/solidity-blog/network/alert/Gemfile.lock/kramdown/open

It can be fixed with

gem "kramdown", ">= 2.3.0" 

but I don't know if that's gonna break anything in the blog's current setup?

How to add a max limit on the burn function with solidity? Actually accumulating the max amount of tokens and triggering the burn function as soon as the max amount reaches? That is, the fee is paid by the end user who reaches the limit. We don't want this situation to happen, what can we do alternatively? Can you help me? Thank you.

Once Sol Underhanded website is ready and live at the right domain summarize the content and make an official announcement on the Solidity blog about the contest.

We want to write a blog post announcing the online setup of the Solidity Summit.

Workflow

• @franzihei to draft post
• @chriseth review
• merge PR / publish blog post

Deadline

This post should be published by Friday, 17th of April .

Link to draft post

https://hackmd.io/@dr56UxqwTjO-0LGQ1GS5Lw/r1QC55rd8/edit

Once the Language Server is in the right shape, let's write a post about it!

We can probably re-use some stuff from @christianparpart's dev.to post. :)

One problem seems to be:

4:57:42 PM: Your bundle is locked to octokit (4.17.0), but that version could not be found
4:57:42 PM: in any of the sources listed in your Gemfile. If you haven't changed sources,
4:57:42 PM: that means the author of octokit (4.17.0) has removed it. You'll need to update
4:57:42 PM: your bundle to a version other than octokit (4.17.0) that hasn't been removed in
4:57:42 PM: order to install.

moved from ethereum/solidity#8057

TO DO before 0.7:

• virtual and override, public vars can override external functions, abstract contracts, no state variable shadowing #38
• push(element) / push() / disallow write access to .length

Done:

• fallback / receive split
• try/catch
• array slices

Postpone / possibly mention in other blog posts:

• global enums and structs (can be covered alongside free functions explanation)
• type(a**x) = type(a), payable(x) conversion for address, f.address instead of address(f)
• _ delimiter for hex strings
• ABIEncdoreV2 no longer experimental, yul optimizer activated together with standard optimizer
• new error reporter
• disable metadata hash / switch to ipfs / swarm
• modifier depth in source mappings
• multiple @returns statements in natspec
• yul / inline assembly: leave

Would an article about past and present team members (and special mentions of external contributors?) make sense?

Or perhaps a short interview article with each members, one at a time?

@chriseth @franzihei opinion?

From @cameel's explanation:

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 (ethereum/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 (ethereum/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 (ethereum/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 (ethereum/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 (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 revealed some irregularities and as result we did some more fixes:
    • Renamed Linux 04.10 binary (ethereum/solc-bin#78)
  • And there are also a few still pending:
    • Replacing Linux 0.4.26 which inexplicably produces differerent (but still valid) bytecode on a single test case out of the 5000 we have (ethereum/solc-bin#80).
    • Windows 0.4.15 reports its version as a nightly and we're going to rebuild it (ethereum/solidity#9545).
    • Emscripten 0.3.6 was not built from the exact commit tagged as 0.3.6 but rather one before and therefore reports slightly different version (ethereum/solidity#10846).

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

Link to the original discussion here.

We want to write a blog post about the new immutable feature. It will be part of the Solidity 0.6.x features series.

Workflow

• @chriseth or @ekpyron to draft post on HackMD
• (technical) accuracy review on HackMD
• @franzihei style/content review on HackMD
• create PR in this repo
• final review
• merge PR / publish blog post

Deadline

This post should be published until XX/XX/XXXX.

Link to draft post on HackMD

We want to write a blog post outlining "array-related bug" see
ethereum/solidity#8560.

Workflow

• XX to draft post
• XX (technical) accuracy review
• @franzihei style/content review
• merge PR / publish blog post once vXX is released

Deadline

This post should be published alongside with the XXXX Solidity release (vXX), presumably on XXXXXX.

Link to draft post

There is already a pull request in the rouge syntax highlighter repository: rouge-ruby/rouge#760

We could create our own package of rouge that has this PR merged (with some modifications to make it 0.6.0-compatible).

We want to write a blog post outlining the work done on the Yul-Phaser.

Workflow

• @cameel to draft post
• @franzihei style/content review
• @chriseth (technical) accuracy review
• merge PR / publish blog post

Deadline

This post should be published by XX .

Link to draft post

We want to update the community more regularly about what we're working on. As part of this effort, let's write about what's the lastest news / interesting stuff happening in the fuzzing land. :)

We want to update the community more regularly about what we're working on. As part of this effort, let's write about what's the lastest news / interesting stuff happening in optimizer land. :)

Could be also part of #138.

See ethereum/solidity#11690 (comment)

It might be worth to write a recap / summary blog post of selected good questions and answers that were posted in the 1st Solidity AMA here: https://www.reddit.com/r/ethereum/comments/jih43k/ask_the_solidity_team_anything_1_ama_in_rethdev/

Shouldn't there be a closing blog post listing all the video links? Or linking to the archive site?

Likewise, how about the findings from the summit surveys? They were posted on twitter, it would be nice to have them shared in a post too.