Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:09

    cburgdorf on master

    Unpin specific nightly This re… Small adjustments for latest ni… (compare)

  • 06:09
    cburgdorf closed #268
  • 01:59
    codecov-io commented #270
  • 01:58
    codecov-io commented #270
  • 01:57
    codecov-io commented #270
  • 01:45
    g-r-a-n-t edited #270
  • 01:39
    g-r-a-n-t edited #270
  • 01:38
    g-r-a-n-t synchronize #270
  • 01:35
    g-r-a-n-t edited #270
  • 01:35
    g-r-a-n-t edited #270
  • 01:35
    g-r-a-n-t synchronize #270
  • 01:30
    g-r-a-n-t opened #270
  • Feb 25 23:06
    g-r-a-n-t synchronize #179
  • Feb 25 18:15
    cburgdorf edited #269
  • Feb 25 09:03
    cburgdorf labeled #269
  • Feb 25 09:03
    cburgdorf labeled #269
  • Feb 25 09:03
    cburgdorf opened #269
  • Feb 25 09:03
    cburgdorf labeled #269
  • Feb 25 08:46

    cburgdorf on master

    Over/Underflow protection for s… (compare)

  • Feb 25 08:46
    cburgdorf closed #267
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> just a thought 🤔
<Grant Wuerker (g-r-a-n-t)> Yeah, I think that's what we want. That mechanism could resemble safe/unsafe rust https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
Ivan Schütz
@i-schuetz
was shortly very excited when I saw Rust in the Readme, but it's just for the compiler :P
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> @i-schuetz Don't be too disappointed. We are big fans of Rust and it is likely to influence the language in certain ways
Ivan Schütz
@i-schuetz
sounds good
Is there a roadmap? when can we start writing production ready contracts with it?
vasa
@vasa-develop
next year
you would have something to work with
Ivan Schütz
@i-schuetz
okay, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> We plan on supporting the features used in erc20 by January. These features will not be audited though, so it shouldnt be used in production.
<Grant Wuerker (g-r-a-n-t)> We'll have a long-term roadmap posted maybe around the time we finish erc20 support.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Interesting memory library for solidity

https://github.com/summa-tx/memview-sol

Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> https://axic.github.io/notes/summit/future_of_solidity/

Interesting slides on soliditys future. Nice to see some overlap in our plans (e.g std library)

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> just flipped thru it. lots of relevant stuff
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> We have first site up at: http://fe.ethereum.org/
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Blogged: Fe Development Update No 1 https://snakecharmers.ethereum.org/fe-development-update-1/
chriseth
@chriseth
Congratulations on your first update! Does fe currently use Yul as the main target or does it also have its own assembler?
Grant Wuerker
@g-r-a-n-t
Thanks @chriseth . We only target Yul and are planning to keep it this way
chriseth
@chriseth
do you have any feedback already? any missing features?
we are planning to add some kind of memory management. This will mean that every opcode that accesses memory will need another parameter that is an opaque handle for an allocated object in memory. If the whole code follows that pattern, these objects can be moved around and allows more opportunities for optimization including moving stack elements to memory
We'll hopefully start implementing that in solidity soon, so we know how it will be working
it will be something like let x := allocate(length) mstore(x, 1, 5)
so in this mechanism, memory offsets will not be relative to the absolute zero but relative to the start of the memory object
the mechanism can be translated into regular evm by implemeting functions like function allocate(len) -> ptr { ptr := mload(0x40) mstore(0x40, add(ptr, length)) } function mstore(obj, offset, value) { mstore(add(obj, offset), value) } - optionally mstore can of course also do bounds checks
Grant Wuerker
@g-r-a-n-t
So far things have worked very well. Off the top of my head, I cant think of any feedback to give. But if we find something that could be improved, we’ll be sure to write an issue in Solidity.
It would definitely be nice have some memory management included in Yul. We’ve been writing lots of boilerplate code for this sort of thing.
chriseth
@chriseth
great, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Thanks for stopping by @chriseth ! I don't have much feedback on YUL itself. I'm still a YUL noob but my interactions with the language so far were fruitful and I'm happy to see how fast we can make progress which I would also attribute to the fact that YUL is already quite expressive for an intermediate language that sits directly above the raw EVM opcodes. One thing that would be nice is to have a standalone YUL library. Currently we are invoking the solidity compiler directly which also means we are building the whole solidity compiler in our build pipeline. Would be nice to have a shortcut since we only depend on YUL.

Also, I'd be curious about your plans to default to YUL in the standard solidity processing pipeline. Do you have an estimate for when that might be achieved (I assume that is the end goal). And when that happens, are you planning to have audits for the YUL compiler? For us it is convenient that Fe and Solidity will eventually converge on YUL which also means there's a whole category of security concerns that Fe and Solidity will share simply by sharing the same IL. At the same time it means that we have a dependency against your roadmap and timeline. So, I'm just curious if you have something to share for us on that front 🙂

chriseth
@chriseth
building the solidity compiler: Have you considered using one of the pre-built binaries from https://binaries.soliditylang.org ? We support windows, macos, linux and wasm / emscripten
A standalone binary is also something we are considering, but not in the near future
We are already pretty far with compiling via yul. The latest compiler provides access to that from the commandline --experimental-via-ir
We will probably have an audit at some point, but there is no date set yet.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Cool. Sounds good! Regarding the pre-built binaries: Yep, we considered it and should probably revisit. It's not a super high priority right now as we aren't distributing the compiler yet. I'm sure Q1 2021 we will have some sort of (premature) release though.
chriseth
@chriseth
are you planning to link against the compiler?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> I think we haven't yet formed a definitive stance on that. We are currently using https://github.com/axic/solc-rust (or better a fork of that) and I think our favourite solution would be to have similar rust bindings but to libyul directly.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> New dev update: https://snakecharmers.ethereum.org/fe-development-update-2/
indolering
@indolering:matrix.org
[m]
Is there discussion anywhere about why K Framework wasn't chosen for the primary implementation?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Grant Wuerker (g-r-a-n-t)> Hello @indolering:matrix.org . It's briefly mentioned on our github page:

A secondary goal to providing a specification document could be to also provide an executable specification via tools such as the K framework. Providing such an executable specification may become a primary goal if it can be achieved without too much effort and without hampering the achievement of other goals.

It's something that I need to look into more.

indolering
@indolering:matrix.org
[m]
Ahh, so it's not that you have tried to use the K Framework before and found it lacking.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> Not at all
indolering
@indolering:matrix.org
[m]
I guess I'm just surprised that you didn't take a formal-verification first approach, given the issues encountered in Solidity and Vyper development.
indolering
@indolering:matrix.org
[m]
... and given the many claims the K Framework makes about getting an efficient runtime and other infrastructure (like a debugger) "for free".
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Grant Wuerker (g-r-a-n-t)> You might be interested in checking out https://github.com/formalize/coq-vyper. It's similar to compcert c and implements a simplified version of Fe (formerly rust-vyper).

With the rust implementation, we're just focusing on getting basic language features working for now, but I'll start digging into the K framework since you've brought it up.

indolering
@indolering:matrix.org
[m]
I'd love a blogpost on how that goes!
wolflo
@wolflo
Hi! Exciting to see another smart contract language emerging. I wanted to say hello and potentially open up a line of communication between the Fe team and ConsenSys Diligence. If there's interest in that, could you let me know the best way to get in touch?
Grant Wuerker
@g-r-a-n-t
Hi @wolflo, thanks for reaching out. I think that would be great. Let me send you my email.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Piper Merriam> Fe binaries work on my machine. Linux, Ubuntu variant, PopOs