by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Simon Shine
    @sshine
    @pldespaigne: When a CALL is made, the return value is pushed to the stack. The stack elements have a fixed size of 256 bits.
    pldespaigne
    @pldespaigne
    Thanks for your answer ! but the yellow paper says that the return value is put in the memory and only a success boolean is push on the stack :/
    pldespaigne
    @pldespaigne
    So after some research it appears that EIP211 with the RETURNDATASIZE opcode is the way to do it
    Ben Scherrey
    @scherrey
    Did everyone stop designing languages for Ethereum? No activity since July or is my cache bad?
    Simon Shine
    @sshine

    No, I'm actually working more on EVM-related stuff now than before.

    But this channel never took off as a live channel.

    Ben Siraphob
    @siraben
    Currently working on a graph reduction machine on the EVM as a target for lazy functional languages to compile too.
    s/too/to
    g. nicholas d'andrea
    @gnidan
    that's neat @siraben !
    Ben Siraphob
    @siraben
    @gnidan Thanks, it was inspired by https://crypto.stanford.edu/~blynn/compiler/c.html
    g. nicholas d'andrea
    @gnidan
    I love when a problem becomes a data structures problem :)
    Ben Siraphob
    @siraben
    Notably, GC is not needed since programs on the EVM don't run for long periods anyway due to gas costs, so we can just keep incrementing the heap pointer.
    Antoine Rondelet
    @AntoineRondelet
    That looks cool @siraben ! Is there an existing Github repo for your project? :)
    Simon Shine
    @sshine
    @siraben I recall someone doing efficient on-chain term reduction of, was it, the lambda calculus? Was that you or someone else? I can't find the link.
    Simon Shine
    @sshine
    @siraben: I was thinking of Victor Maia's Formality: https://medium.com/@maiavictor/introduction-to-formality-part-1-7ae5b02422ec -- he does a very efficient translation of beta reductions: https://medium.com/@maiavictor/compiling-formality-to-the-evm-99aec75677dd
    Ben Siraphob
    @siraben
    @AntoineRondelet no repo yet, currently a gist, once my uni year is over I'll turn it into a repo
    Hm, mobile gitter seems to make it difficult to paste
    I'll use Oleg's semantic translation of λ-calculus to SKI and see how gas costs fare.
    Simon Shine
    @sshine
    @siraben What's the goal of lazy evaluation on chain?
    Ben Siraphob
    @siraben
    @sshine The lazy semantics comes from the graph reduction. Of course, I'll add IO (in the Haskell monadic sense) and thus allow for sequencing of programs.
    I don't have concrete numbers on gas usage yet, but if they are unacceptably high, I will opt for a typed Forth-like language for ease of writing the compiler.
    Ben Siraphob
    @siraben
    If anyone has familiarity with the Spineless-Tagless G Machine, I'd be interested in discussing how to implement it efficiently on the EVM.
    @sshine I notice you've been working on Lira, how is that project going?
    Simon Shine
    @sshine
    @siraben: I was working on Lira in the past because the guys who wrote it are friends of mine. But I'm currently working on Lira in capacity of my current job. I'm still mostly cleaning up stuff as we're determining how to progress with it. It is my impression that a lot of the interesting code being pushed on-chain today is related to settlement of leveraged assets. Lira is currently fully collateralized.
    Simon Shine
    @sshine

    @siraben: I haven't tried to implement a lazy functional language before, but I think I understand the basic ideas.

    I like the idea of your runtime being a graph of combinators, since any formalisation of the high-level language maps closely to the combinator representation. So if you prove that your translation of the combinators to EVM instructions is correct, then you have a kind of two-step proving strategy for executing verified code.

    @siraben: I look forward to hearing from you what the cost is.
    Simon Shine
    @sshine
    @siraben: The other angle I've been investigating in terms of proving things about the runtime of a contract is the "Calculating Correct Compilers" approach by Patrick Bahr and Graham Hutton. (Bahr is incidentally the guy who formalized the language Lira is based on, and Hutton is the guy who wrote that Haskell book.) So we're in good company.
    (There's one booklet for each of register-based and stack-based machines)
    Ben Siraphob
    @siraben
    Oh! I read that paper recently, it's very good.
    @sshine I see. I'll take a look at Lira, there are some interesting approaches it takes.
    Ben Siraphob
    @siraben
    There's a couple of things I can do to improve gas costs, I'm going to widen the size of each cell from 16 bits (used for debugging purposes) to the full 256 bits, which will reduce gas costs since my read/write routines take multiple instructions.
    Perhaps move to some jump table for executing combinators, instead doing dup X = (jumpi execX) each time
    Simon Shine
    @sshine
    @siraben: If there's anything you'd like to know about Lira, let me know. There are a few neat things about the translation, but it's still very much a proof-of-concept.
    @siraben: In particular it mostly lacks the re-design cycle of "it's been running, now what isn't working so well" -- there was one addition by my colleague that enabled entrance into the contract possible after deployment. Before that you'd have to know the addresses of parties when compiling the contract.
    @siraben: With the language being so high-level, it says very little about how to actually execute the contract, so the same contract could have any number of execution semantics, of which only two have been explored so far. I'm sure there are others that are generally much more usable.
    Simon Shine
    @sshine
    @siraben: E.g. having the deployed contract be a factory of parameterised instances, so that multiple sets of parties can run the same contract at different times without having to re-deploy the entire contract to have e.g. the timestamps or the counterparties change.
    Simon Shine
    @sshine

    On another note, to everyone: Has anyone went and used DAML yet?

    This looks like the only declarative, general-purpose contract language out there with any momentum.

    (Lira isn't general-purpose, and it has less but positive momentum. Also, Lira was made by Thorkil Værge and Mads Gram, I'm only the custodian.)
    Ben Siraphob
    @siraben
    @sshine Lira seems interesting, how would something like an ERC-20 token work in the declarative syntax?
    I haven't done much work in declarative languages, so it's likely the language we're making will be general purpose at first, with additional libraries over time.
    By execution semantics are you referring to strict/non-strict evaluation strategies or something else?
    Simon Shine
    @sshine

    @siraben What is your language's current goals, besides lazy evaluation as a proof-of-concept?

    How something like an ERC-20 token works in declarative syntax: Easily. When you think about it, "Create your own ERC-20 token" websites give the recipe as a static 4-tuple of (Name, Symbol, Decimal Places, Total Tokens). So this is the simplest mainstream declarative recipe for an ERC-20 token. So we add more rules on top to resemble classical financial derivatives, like time/oracle/conditional primitives.

    How Lira does it is that you hoist out contract calls, so rather than a syntax tree that contain transfers, you turn that into a list of transfers and some chunk of logic that determines if those transfers are to be made. In Lira's example, the logic that evaluates "if-within" for oracles depends on persistent storage memory so that an oracle that was once true during a condition's time-interval isn't checked again.

    What I mean by execution semantics is that right now, a Lira contract can be deployed with all counterparties known beforehand, or counterparties can be added after contract deployment (but before contract execution initiates). This last run-mode was added later. But each contract deployment represents one instance of the contract being executed with one set of counterparties and one set of potential transfers.

    So for CPU you care about strict/non-strict evaluation because it addresses resource concerns and expressibility.

    For declarative blockchain languages it could mean the same, but it could also mean "how do we actually execute this contract wrt. all the bits that the language is being implicit about?" -- for example, there is no explicit address book feature in Lira, and the implicit quantifiers for the counterparties are assumed to be "for exactly one party A, B and C:" But if it were a "for all parties A, B and C:" then the contract could be kind of like a factory (as in the OOP pattern) as I said.

    Simon Shine
    @sshine

    Another thing about execution semantics: You might want to check some parts of a conditional first because it's cheaper rather than because it's listed first. (Even && in Haskell evaluates from left to right, but there are languages where even the order of execution of individual lines of code is non-deterministic because they're independent.) You might fold/optimize certain expressions at compile-time, or you might not.

    You might even have an implicit cash-out retention policy as part of your execution semantics; after all, a part of execution cost suddenly involves interest rates. :D

    "Please wait for optimal weather conditions while the right-hand side of your && evaluates." :D
    Ben Siraphob
    @siraben
    @sshine The lazy functional language on EVM was just a proof-of-concept, more or less. Currently working with @scherrey on a typed concatenative language à la Forth.
    The difficulty of predicting runtime cost (and thus gas cost) may make laziness unsuitable for Ethereum, at least from what I understand.
    Thanks for the further explanation on Lira, that's very interesting indeed, that you can add such primitives to achieve what looks like financial modeling directly on smart contracts.
    Simon Shine
    @sshine

    @siraben Cool. :) So your angle is still purely language-expressivity rather than solve some particular business problem?

    I suppose you can see any Solidity contract as a financial derivative, but before this comparison is truly impressive is when you can only exactly express things that people would normally do in financial derivatives and not a bunch of wrong stuff. Like, if you took someone who worked in the legal dept. of an exchange and showed him contract code and he/she'd say "yeah, that's this-and-that derivative."

    I guess there were historical paper contracts where you use the actual piece of contract paper for keeping score of execution progress (stateful contract), but typically you will just want to say what kind of book-keeping you expect to happen, and the executors of the contract will manage it sensibly. This reminds me of the tally sticks that resulted in the burning of British parliament: https://en.wikipedia.org/wiki/Burning_of_Parliament

    Pro tip: Don't make your blockchain flammable.