TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#1

Post by bobbrown » Tue, Dec 12, 2017, 3:35 PM UTC

TypeChain: TypeScript Bindings for Ethereum Smart Contracts
blog.neufund.org

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#2

Post by eximius » Tue, Dec 12, 2017, 4:04 PM UTC

Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc?

I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#3

Post by itsnotlupus » Tue, Dec 12, 2017, 4:31 PM UTC

eximius wrote: post #2

Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc? I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.

Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#4

Post by ChrisRus » Tue, Dec 12, 2017, 4:34 PM UTC

I wrote ARCcore.filter to solve many of the issues discussed. And, because it works at the JavaScript function level to normalize/validate function I/O it works well with _everything_ to solve the runtime data problem. And, it opens up a new world of type-based runtime metatemplate programming to JavaScript developers. https://encapsule.io/docs/ARCcore/filter

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#5

Post by eximius » Tue, Dec 12, 2017, 4:43 PM UTC

itsnotlupus wrote: post #3

eximius wrote: post #2

Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc? I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.

Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.

Formal verification is needed but syntactic sugar is not inherently the problem. The problem is that there a a million gotchas because it looks high level, but isn't.

Defaulting to `storage` instead of `memory` for variables is one huge issue that can let you silently corrupt your contract.

Lack of builtin manipulation of datatypes, weird types that are cumbersome to use correctly...

I am not equipped to exhaustively lament it as a language, but it is not a pleasant experience.

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#6

Post by j_s » Tue, Dec 12, 2017, 4:54 PM UTC

eximius wrote: post #5

itsnotlupus wrote: post #3

Earlier quoted context omitted.

Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.

Formal verification is needed but syntactic sugar is not inherently the problem. The problem is that there a a million gotchas because it looks high level, but isn't. Defaulting to `storage` instead of `memory` for variables is one huge issue that can let you silently corrupt your contract. Lack of builtin manipulation of datatypes, weird types that are cumbersome to use correctly... I am not equipped to exhaustively…

Understanding Ethereum Smart Contracts | https://news.ycombinator.com/item?id=15786780

HN user jatsign shared some of his inital gotchas two weeks ago.

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#7

Post by buybackoff » Tue, Dec 12, 2017, 5:39 PM UTC

We wrote a library with the same code generation purpose almost on the same day (1st commit). I just found myself typing the same TS code using truffle-contract lib over ERC20 methods. Using it in production and will release v.1. as soon as web3 is v.1. (a blog post was due on v.1 date :) ) We also have a number of strongly typed helper methods included such as ethereum-utils, keythereum and fast signing for state channels implementation (implemented in a sibling repo). The concept of TypeScript code generation is very valid, saves a lot of time during rapid prototyping and contracts become self-documenting, with IDE errors after signatures change. Generated contracts are isomorphic and work well from Node.js and a browser while being simply packed with NPM. https://github.com/dbrainio/Soltsice

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#8

Post by krzkaczor » Tue, Dec 12, 2017, 7:25 PM UTC

buybackoff wrote: post #7

We wrote a library with the same code generation purpose almost on the same day (1st commit). I just found myself typing the same TS code using truffle-contract lib over ERC20 methods. Using it in production and will release v.1. as soon as web3 is v.1. (a blog post was due on v.1 date :) ) We also have a number of strongly typed helper methods included such as ethereum-utils, keythereum and fast signing for state ch…

Hey, TypeChain author here.

Yeah that's funny :D I was looking for a tool like that, haven't found anything so I wrote my own. Now it seems like there is a couple of tools doing similar things (also 0x is working on something similar).

Good luck with your project — your approach is a little bit different since you wrap around truffle contract where we decided to come up with our own api. I am excited to see how it develops further!

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#9

Post by krzkaczor » Tue, Dec 12, 2017, 7:27 PM UTC

eximius wrote: post #2

Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc? I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.

Sorry, this is for communicating with the already deployed contract.

Re: TypeChain: TypeScript Bindings for Ethereum Smart Contracts

#10

Post by buybackoff » Wed, Dec 13, 2017, 12:32 AM UTC

krzkaczor wrote: post #8

buybackoff wrote: post #7

We wrote a library with the same code generation purpose almost on the same day (1st commit). I just found myself typing the same TS code using truffle-contract lib over ERC20 methods. Using it in production and will release v.1. as soon as web3 is v.1. (a blog post was due on v.1 date :) ) We also have a number of strongly typed helper methods included such as ethereum-utils, keythereum and fast signing for state ch…

Hey, TypeChain author here. Yeah that's funny :D I was looking for a tool like that, haven't found anything so I wrote my own. Now it seems like there is a couple of tools doing similar things (also 0x is working on something similar). Good luck with your project — your approach is a little bit different since you wrap around truffle contract where we decided to come up with our own api. I am excited to see how it de…

Hi! Thanks! I will replace truffle-contract with web3 1.0 contracts API. Current web3 1.0-beta doesn't work well with TS. The dependency was accidental since I was already using it, while writing codegen stuff took very little time and was just a helper script in a contracts repo initially. Our public API is plain async TS, truffle-contract is only an implementation detail.

Need for such solution seems so obvious given that we have Go ABI gen tool for a similar purpose and JS is the main language for DApps (and probably Node.js for backend is more popular than Go). Also, truffle migration looked like a fragile black box, and testing with `jest --watch` instead of truffle suite is much nicer and faster.