@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
Subscribe to msfew
Subscribe to msfew
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
We at Hyper Oracle have recently been building a Subgraph-like zkGraph for developers to write data mapping that can be converted into ZK circuits.
In developing zkGraph, I've drawn inspiration and experience from a number of components in The Graph, as well as attempting to make it backward-compatible to Subgraph.
I've taken a closer look at graph-ts, a library developed for Subgraph, and have some thoughts on it.
If you follow the documentation in their repo to download the npm library and use it in an AssemblyScript project, you'll find that there's no way to use it directly without the other graph cli.
This is related to the following point. There is no way to use this library on its own, which is confusing.
Most of graph-ts is implemented in AssemblyScript, but there are a lot of functions that are just defined in AssemblyScript and not implemented. The implementation is in the Graph Node, which is in Rust.
The main reason for this may be performance, or problems with the AssemblyScript language in early days. See discussion here. Side note: AssemblyScript is sponsored by Near, The Graph, and Shopify, so they are basically the early and the only adopters lol.
As a result of having more than one implementation language, you can't compile the whole graph-ts individually. Also for developers like me who want to achieve Subgraph compatibility, it's very difficult to guess all the functionality and behavior.
People are saying BigInt api is not cool. BigInt's math operations are called plus, minus, times, not add, sub, mul as is the normal JS convention. It's possible to use operators like "+, -, *" directly, but the IDE tends to complain.
In the zkGraph implementation, we support both plus and add operators for Math, so both can be used.
little-endian is the default in graph-ts. But in reality, all of Ethereum's scenarios use big-endian. I think The Graph may have adopted little-endian, which is more common in all scenarios, for the sake of generality.
In zkGraph, we have implemented a similar little-endian function and an additional big-endian version.
Some conversion functions are weird. For example, toHex and toHexString behave the same, which is redundant. It’s probably, again, the legacy of AssemblyScript.
I submitted a pr, but it’s still pending. In zkGraph, toHexString can take a prefix as input, or if there’s no input, then it’s the same as toHex.
Overall, the documentation is very good, but it always feels like it was good in the first version and has not been updated accordingly.
For example, there are many functions that are in the implementation, but not in the documentation.
We at Hyper Oracle have recently been building a Subgraph-like zkGraph for developers to write data mapping that can be converted into ZK circuits.
In developing zkGraph, I've drawn inspiration and experience from a number of components in The Graph, as well as attempting to make it backward-compatible to Subgraph.
I've taken a closer look at graph-ts, a library developed for Subgraph, and have some thoughts on it.
If you follow the documentation in their repo to download the npm library and use it in an AssemblyScript project, you'll find that there's no way to use it directly without the other graph cli.
This is related to the following point. There is no way to use this library on its own, which is confusing.
Most of graph-ts is implemented in AssemblyScript, but there are a lot of functions that are just defined in AssemblyScript and not implemented. The implementation is in the Graph Node, which is in Rust.
The main reason for this may be performance, or problems with the AssemblyScript language in early days. See discussion here. Side note: AssemblyScript is sponsored by Near, The Graph, and Shopify, so they are basically the early and the only adopters lol.
As a result of having more than one implementation language, you can't compile the whole graph-ts individually. Also for developers like me who want to achieve Subgraph compatibility, it's very difficult to guess all the functionality and behavior.
People are saying BigInt api is not cool. BigInt's math operations are called plus, minus, times, not add, sub, mul as is the normal JS convention. It's possible to use operators like "+, -, *" directly, but the IDE tends to complain.
In the zkGraph implementation, we support both plus and add operators for Math, so both can be used.
little-endian is the default in graph-ts. But in reality, all of Ethereum's scenarios use big-endian. I think The Graph may have adopted little-endian, which is more common in all scenarios, for the sake of generality.
In zkGraph, we have implemented a similar little-endian function and an additional big-endian version.
Some conversion functions are weird. For example, toHex and toHexString behave the same, which is redundant. It’s probably, again, the legacy of AssemblyScript.
I submitted a pr, but it’s still pending. In zkGraph, toHexString can take a prefix as input, or if there’s no input, then it’s the same as toHex.
Overall, the documentation is very good, but it always feels like it was good in the first version and has not been updated accordingly.
For example, there are many functions that are in the implementation, but not in the documentation.
No activity yet