Basic contract metadata proposal #3

bowenwang1996 · 2019-06-25T19:58:51Z

@vgrichina feel free to change things/add more stuff.

vgrichina

I think it'll be nice to have a good example of real-life methods, corresponding pretty-printed generated JSON and metadata method.
That would be the meaty part, cause we already discussed motivation, etc

bowenwang1996 · 2019-06-25T22:04:36Z

@vgrichina updated example

DanielRX · 2019-06-28T15:17:18Z

After reading this I had a few questions:

Does metadata() get included in the returned JSON from metadata()?
Would it work to store the length of the metadata (when tightly packed) and the length of the contract bytecode, and simply read from memory(contractStartLocation + contractLen, metadataLength) in order to get the metadata? It would mean no more metadata function, but slightly more work on the side of the reader (however any client could easily build a quick memory read + parse function)
Would return type narrowing make sense for constant methods? (In your first example the return type could be narrowed to "Hello World" which means you could instead just read from the metadata, rather than calling the getter

bowenwang1996 · 2019-06-28T16:20:40Z

metadata itself is not included because the purpose is to get the list of existing methods that is otherwise hard to obtain. As every contract has this method, I don't quite see the point of including metadata itself in the returned json.
The idea is that we don't want developers to deal with memory directly. So if we store the location in memory and length, we still want to have some method that reads it, which could be something to consider, but it is more involved on the implementation side.
The point of metadata is not to evaluate the function, but rather to show what methods (and their types) a contract has. We potentially want to also have annotations included in metadata as well. @vgrichina can provide more info on this.

DanielRX · 2019-06-28T16:42:35Z

Then the definition Every contract will have a metadata method that returns a json that serializes the contract methods is not correct, the metadata method is a method on the contract, so falls under the contracts methods surely?
Do you intend for developers to directly access metadata() or for them to get it via a client implementation? If you have a ts library for accessing a contract, that library just simply needs to add the memory function there. The question is more catering to size, storing another method, and a full JSON object, is going to be large compared to a fixed memory location
The type narrowing is not evaluation of a function, it's a feature in ts
The type of const x = 1; is not number, it's 1, so it gives better auto completion and intellisense
If you have a function () => 1 the return type comes out as 1 because it is a constant value, meaning you don't need to evaluate it to use the value, it becomes referentially transparent in it's type

bowenwang1996 · 2019-06-28T16:55:11Z

It depends on what you mean by contract methods. What I meant is all the contract methods that a developer wrote. metadata is generated so even though it is technically a method on the contract, I didn't consider it to be a contract method. I'll revise the wording to be more precise.
Yes the intent is that developers can directly call metadata and return a json to the frontend. We have a library and could do it there as you suggested. I just need to think more thoroughly about implementation.
Ah I see. Please forgive my ignorance. But I guess autocompletion doesn't really matter here and the point is to make it easily understandable, so we'll probably stick with the current design.
Also the current implementation is here in case anyone is interested.

DanielRX · 2019-06-28T17:01:58Z

As an aside, is this issue meant to be discussing the implementation of the metadata, or the general idea of some metadata being added? As I noticed a small change to the JSON that can save a few bytes (and a different format that would reduce the size by ~60%)

bowenwang1996 · 2019-06-28T17:04:26Z

The implementation details should probably be discussed in this PR. Please note that the commit history is somewhat messed up right now because of some backlog on our end.

vgrichina · 2019-06-28T17:29:18Z

@DanielRX we use JSON at many places cause it's easy to work with, especially when debugging. At some point we'll add compression and may switch to some more efficient (but semantically compatible) format like MessagePack.

I wouldn't worry too much about optimizing size before compression, cause it's not really scalable – compressing all data going to be bigger win then saving on field names.

eriktrautman · 2019-07-05T21:54:02Z

Some UI usage: References near/near-wallet#66 (comment)

DanielRX · 2019-07-07T15:20:13Z

Given the addition of the decorators for the metadata, are they enforced?
Can I use @view_method on a function that is clearly not view? If so, is it not possible to infer the modifier where one is missing (so as to add it for the compiler to output)
Something like "function add was missing a state modifier, it looks to be a view function, please add @view_method if that is correct"

bowenwang1996 · 2019-07-07T17:14:01Z

I don't think that's possible to do given that the compiler knows nothing about state. So if you annotate a state-changing function with @view_method, it will return an error during execution https://github.com/nearprotocol/nearcore/blob/0d163dfa44dd333a0a2a50fe7edd023e392662aa/runtime/runtime/src/state_viewer.rs#L158.

text/0000-contract-metadata.md

vgrichina · 2019-07-11T00:27:17Z

text/0000-contract-metadata.md

+This contract has two change methods, `incrementCounter` and `decrementCounter`, as well as one view method, `getCounter`.
+In this case, the metadata we want looks like 
+```json
+[


This looks good but kinda still seems not diverse enough. E.g. it is not clear how do we represent nested objects, arrays, strings, uint128, etc.
Maybe we need few examples to cover it doesn't have to be single contract.

MaksymZavershynskyi · 2019-07-23T20:43:48Z

text/0000-contract-metadata.md

+# Motivation
+[motivation]: #motivation
+
+Currently there is no direct way for a developer to programmatically list the methods of a contract that is deployed on chain


Technically, this is not correct. If names were mangled host wouldn't be able to call the method from Wasm. The argument names might be mangled though.

Are the names stored in a table or are they in a header file, or something else? If the names and types and offsets of all functions are programmatically available already, the metadata wouldn't need any of that?

I leave this research to @bowenwang1996 . I just know for a fact that names are not mangled, because host calls functions in Wasm by their names.

I don't think the names are stored anywhere. Only the function names are available. Also because wasm only has i32, i64, f32, and f64, all the type information is erased.

We should figure out it for a fact, for instance, find it in the Wasm spec, or ask it from someone developing Wasm or Wasm-related infra (you can ask Max).

Also because wasm only has i32, i64, f32, and f64, all the type information is erased.

I don't see how this:

Also because wasm only has i32, i64, f32, and f64

implies this:

all the type information is erased.

I suggest we do not do own our deduction, and either find it in the Wasm spec or talk to the Wasm team.

http://webassembly.github.io/spec/core/text/types.html

Can you elaborate on this link?

Also, did you look into how Wasm preserves the names of the functions? I am pretty sure they are not mangled, otherwise we would not be able to call functions by name from Wasmer.

The link says the parameter of a function takes valtype, which is one of i32, i64, f32, f64.

Cool, I see now that argument names are not preserved. Thank you. Could you do now the research on how function names are handled in Wasm?

text/0000-contract-metadata.md

MaksymZavershynskyi · 2019-07-23T20:50:11Z

text/0000-contract-metadata.md

+For developers, there will be two main changes:
+- Instead of annotating view and change methods in the `initContract` function in `main.js`,
+they will instead annotate the methods of a contract by decorators.
+More specifically, every method is by default a change method, unless annotated by `@view_method`.


I suggest that all our methods are callable as near call and near view independently on whether they change the state or not. We should remove the current constraint the prohibits calling near view on methods that mutate the state. There are not safety concerns to have this constraint. @evgenykuzyakov @ilblackdragon

it's not about safety, it's about developer experience. If I call the function and it didn't purist state change silently I won't know WTF is going on.

If you are calling near view then you know that it has no permanent effect on the state, because you read near view --help before calling it :)

On this point, does a view contract function have the restriction that it can't call a non-view function?

Yes. Right now if you call a state-changing function within a view function, the execution will fail.

In the proposed change by max, that will not error but the state will not be changed instead.

The two should be consistent though? Either they both error or neither error?

I still think there is some advantage of being explicit. The annotation serves as documentation for developers who might interact with the contract and with metadata, the list of view methods can be easily extracted and displayed, which is better, in my opinion, than looking at the source code and tries to understand for each function, whether it changes the state or not.

From today's hackathon, the distinction between view and change methods should be either strictly enforced (and extensively documented), or their functionality should be merged into a single kind. Otherwise, it gets really confusing and error-prone.

Okay it seems like the distinction is confusing. I think we should eliminate the difference and allow dry run of change methods. One thing that is not clear to me is how we should support cross contract view calls. It seems that if you pass 0 gas, the instantiation of wasm module for the call on the second contract will fail.

text/0000-contract-metadata.md

MaksymZavershynskyi · 2019-07-29T17:28:13Z

I think we should compare how other blockchains are doing metadata for their contracts. We need to make sure this design is solid because we won't be able to iterate on it neither through governance nor forks; at least not without losing contracts that are already compiled to Wasm.

Please check https://github.com/paritytech/ink and other blockchains that you can find.

DanielRX · 2019-07-30T08:01:15Z

I think we should compare how other blockchains are doing metadata for their contracts. We need to make sure this design is solid because we won't be able to iterate on it neither through governance nor forks; at least not without losing contracts that are already compiled to Wasm.

Please check https://github.com/paritytech/ink and other blockchains that you can find.

Would it make sense to add some form a version to the schema, which would in effect allow iteration (as older contracts can "work" via an compatibility tool for parsing). This would also allow for some level of flexibility for backwards compatible changes to the metadata.
EDIT: Also, is the compiler version and WASM version going to be encoded into the metadata?

An alternative I would suggest is make the metadata "output" as close to binary and low level as possible, and support the JSON or YAML or any other human readable format, as part of the near client instead of the chain data directly (this means you can have simple parsers for the basic serialisation formats and enables all developers to work in the format they are already using for configs, static data and general use).

Binary data (simply the name, types and some other basic data like view and public/private) would be fairly robust since you aren't adding anything extra (and anything extra added after such data, could easily be combined with extension).
If you choose JSON as a direct output by the contract, you risk being very locked into it. The output from the contract (in my mind) should be a compact, machine readable output, and the clients should support parsing such data into human readable format.

One final comment I have is "Why must the data be returned inside of the contract?" Is there no "data" protocol you could use to store this, which would allow the same UX, but without bundling it onto the contract itself. Something like an IPFS hash of the file (with all files pinned) would provide the data in a computer readable format, while having an option to update the format in the future.
If the files were hosted on a "data" section, you could generate a system for updating a contracts "ABI" or "Metadata" from the data section. This would mean you wouldn't need to worry about already compiled contracts.

bowenwang1996 · 2019-07-30T16:34:12Z

I think we should compare how other blockchains are doing metadata for their contracts. We need to make sure this design is solid because we won't be able to iterate on it neither through governance nor forks; at least not without losing contracts that are already compiled to Wasm.

Please check https://github.com/paritytech/ink and other blockchains that you can find.

Does parity have anything related to metadata? I didn't find any but maybe I missed something.

MaksymZavershynskyi · 2019-07-31T17:10:40Z

I think we should compare how other blockchains are doing metadata for their contracts. We need to make sure this design is solid because we won't be able to iterate on it neither through governance nor forks; at least not without losing contracts that are already compiled to Wasm.
Please check https://github.com/paritytech/ink and other blockchains that you can find.

Does parity have anything related to metadata? I didn't find any but maybe I missed something.

As I mentioned above, the conventional name for contract metadata is ABI. Search for ABI in the link. But also, please don't wait for me to do the research and send you the links, there are prominent blockchains that have ABI, e.g. Ethereum https://solidity.readthedocs.io/en/develop/abi-spec.html#

janedegtiareva · 2019-07-31T18:16:42Z

text/0000-contract-metadata.md

+also contained in the metadata.
+
+# Motivation
+[motivation]: #motivation


I think we need to also include app title in the metadata.
If we look at playstore app submission process, it requires devs to fill in some display info for the app so that it can be listed in various UI contexts. For us, this might mean displaying the name of the app in the wallet for authorization, and/or NEAR app listing. This data may need to be localized if we want to support multiple languages in the future. Google in fact provides easy integration with their translation service in case the developer is unable to translate in-house.

For more info on play store app submission process see https://themanifest.com/app-development/how-publish-app-google-play-step-step-guide -- see product details section.

This sounds very much to me as following on from https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md With the idea of being able to add domain specific values (like app title) in a way that humans can verify it. Would it make sense to include all of this on contract, or out of band / on a separate part of the protocol?

EDIT: What would an exhaustive list of keys be that would be needed for every app, but not so large as to mean the majority of apps have "random_hex_string" as a placeholder to satisfy the requirements?

vgrichina · 2019-07-31T22:31:19Z

Would it make sense to add some form a version to the schema, which would in effect allow iteration (as older contracts can "work" via an compatibility tool for parsing). This would also allow for some level of flexibility for backwards compatible changes to the metadata.

@DanielRX @bowenwang1996 yes, we totally should have version of our build tools in metadata.

bowenwang1996 · 2019-07-31T22:32:09Z

Agree. Will update this when I have time

DanielRX · 2019-08-01T13:08:42Z

ABI vs Metadata

As I mentioned above, the conventional name for contract metadata is ABI. Search for ABI in the link. But also, please don't wait for me to do the research and send you the links, there are prominent blockchains that have ABI, e.g. Ethereum https://solidity.readthedocs.io/en/develop/abi-spec.html#

The other item that appears for ABI when searched for, is in swift: https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md but this is to do with how binary objects interface, while this proposal is more tailored towards how various properties of a contract can be accessed from the libraries/developer tools.

This to me seems like it is a feature not typically put onto the protocol level but the contract level (which is then put into the "protocol" level due to support for a specific form of ABI).

The way I would view the naming of the spec (ignoring the fact this is bikeshedding at this point):
The ABI defines the interface of the contract, the metadata encompasses this and the static / related properties of the contract (size, name, shard (if it were static), owner (if it were to be a standard to have all contracts have owners)) so I would say ABI as a name only covers the interface.

Location of storage

Is there a more logical location to store the metadata of the contract?

Should it be stored in the code storage of the contract, or in a separate area (which lends itself to a much more "focused" area to find the data).

If it were to be stored in a separate area, you could almost imagine it something like

/* on deploy (or compiled into constructor) */
metaStorage.set(contractLocation, metaDataString);

or better:

/* on deploy (or compiled into constructor) */
// metaStorage would use `context.sender` as the key to store it under,
// preventing anyone but the contract editing it
metaStorage.set(metaDataString);

DanielRX · 2019-08-16T11:36:29Z

Should the metadata string be signed, allowing for uses and consumers of the data to verify that the metadata belongs to the same contract they intend?

It would be possible to do this on deploy (since the name it's stored at is not included on compile) or it could be bundled with the compiled code if the name was compiled with it.

MaksymZavershynskyi · 2019-09-03T00:01:39Z

The ABI defines the interface of the contract, the metadata encompasses this and the static / related properties of the contract (size, name, shard (if it were static), owner (if it were to be a standard to have all contracts have owners)) so I would say ABI as a name only covers the interface.

I agree, this sounds like a valid separation of abstractions.
Metadata then consists of:

ABI -- pure syntactic description of contract interface;
Semantic ABI -- e.g. minimum value of gas that the function expects, under which conditions it will reject the call, etc.
static data, like author's name, description, license (similarly to metadata of Rust crates, example );

MaksymZavershynskyi

This looks very good.
Please do not forget to add a subsection "Contract Metadata" to "Runtime" section in https://nearprotocol.github.io/nomicon/ that includes the final spec, once the implementation is done.

MaksymZavershynskyi · 2019-09-18T09:54:03Z

text/0000-contract-metadata.md

+* `Seq<T>`: A variably sized homogeneous sequence of values, for example `Vec<T>` or `HashSet<T>` in Rust, `Array<T>` in
+AssemblyScript.
+* tuple: A statically sized heterogeneous sequence of values, for example `(u8, string)`. This doesn't apply to AssemblyScript.
+* `Map<K, V>`: A variably sized heterogeneous key-value pairing, for example `BTreeMap<K, V>` in Rust and `Map<K, V>` in AssemblyScript.


Dropping variants was a good call, they are too Rust-specific.

MaksymZavershynskyi · 2019-09-18T10:08:12Z

text/0000-contract-metadata.md

+Currently there is no convenient way for a developer to programmatically list the methods of a contract that is deployed on chain
+because the contract code stored on chain is the compiled wasm code, where the parameters and type information are already mangled (even though
+method name is not, it is still cumbersome to extract them from wasm binary).
+As a result, if developers want to display the methods of a contract to an user of the app to provide transparency,


As discussed with @bowenwang1996 before I think the only real application of the contract metadata is input validation. The case when front-end is somehow implemented to not have hardcoded dependencies on method or argument names has several issues:

As discussed, it is very unlikely that front-end developer will somehow use a contract method without using the name of the method anywhere in their code (because they at least need to identify it) so if the contract method name changes they would have to manually modify the code anyway;

It opens a huge security concern and such usage should be in general discouraged. We need to have a section in this NEP and documentation explaining the following example: Suppose someone malicious implements a contract with method burn(gas_in_thousands: u64) and lets other developers to use it in their front-ends. Then malicious contract developer changes the signature of the function to be burn(gas: u64) without announcing to anyone. If front-end did not break because it has automatically rebound to the the argument name the users now are burning 1000 more gas without having any notification. The core problem with metadata is that it does not describe semantics, it describes syntax

As discussed with @bowenwang1996 before I think the only real application of the contract metadata is input validation.

As well as it allows to generate a wrapper which would automatically encode/decode ABI (which could be considered as an input validation too).

MaksymZavershynskyi · 2019-09-18T10:09:22Z

text/0000-contract-metadata.md

+[guide-level-explanation]: #guide-level-explanation
+
+With contract metadata, developers, instead of annotating view and change methods in the `initContract` function in `main.js`,
+will instead annotate the methods of a contract by decorators. We propose that view functions be annotated with the `@view` decorator


Suggested change

will instead annotate the methods of a contract by decorators. We propose that view functions be annotated with the `@view` decorator

will instead annotate the methods of a contract by decorators. We propose that view functions be annotated with the `@view` decorator in AssemblyScript (in Rust there is no need for additional decorators)

How do we plan to do this in Rust? This decorator doesn't enforces anything but rather serves as a way to document the function.

Technically it's distinguished by the borrowing type of ABI method in implementation (fn method(&mut self) or method(&self) for view). See
https://github.com/nearprotocol/near-bindgen/blob/master/examples/status-message/src/lib.rs

MaksymZavershynskyi · 2019-09-18T10:11:45Z

text/0000-contract-metadata.md

+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+To implement this NEP, we need to modify the binding generation procedure to generate a method called `metadata` that returns


Suggested change

To implement this NEP, we need to modify the binding generation procedure to generate a method called `metadata` that returns

To implement this NEP, we need to modify the binding generation procedure in AssemblyScript compiler to generate a method called `metadata` that returns

MaksymZavershynskyi · 2019-09-18T10:12:19Z

text/0000-contract-metadata.md

+To implement this NEP, we need to modify the binding generation procedure to generate a method called `metadata` that returns
+json serialization of contract metadata described in the previous section. This involves an AST walk to collect the relevant
+ information about functions and classes, as well as mapping types to the types used in metadata.
+


Suggested change

In Rust we would need to augment the procedural macro to inject the metadata method.

vgrichina · 2019-09-18T18:13:14Z

text/0000-contract-metadata.md

+                  "fields": [{"name": "id", "type": "string"}, {"name":  "title", "type": "string"}, {"name": "completed", "type": "bool"}]
+                }
+              ],
+   "contract": {"name":  "Todo list", "description": "A todo list on blockchain!"},


contract name / description need to be localizable

wonder if maybe it makes sense to keep it in separate metadata, so that user can call it like description(userLocale) and get this info for given locale.

bowenwang1996 · 2019-09-24T22:14:49Z

Update: due to technical difficulties, we will not have contract metadata support for rust in the near future. Related issue: rust-lang/rust#44034

MaksymZavershynskyi · 2019-11-19T22:54:00Z

We should investigate whether WAI https://medium.com/wasmer/introducing-webassembly-interfaces-bb3c05bc671 can be used here as a drop-in universal solution. Pros: If it works we will be compatible with other Wasm infrastructure that supports WAI, e.g. Wasm package manager.

lexfrl · 2019-11-20T13:42:40Z

Consider to use custom section as a good place to store metadata. wasm-bindgen uses it to store metadata as well as in Wasm Interface Types proposal.

MaksymZavershynskyi · 2020-03-10T22:27:45Z

We have implemented metadata for Rust contract in this PR: near/near-sdk-rs#99 The format is quite different from the one described in this PR.

The explanation of the metadata format consists of mostly explanation of Borsh Schema format introduced here: near/borsh#56 and near/borsh#57 Since we don't have that documentation yet, I suggest we do not push this PR and instead later simply add documentation for Borsh Schema and metadata as a part of documentation work. CC @amgando @mikedotexe Therefore I am closing this PR

Basic contract metadata proposal

10854b9

bowenwang1996 requested a review from vgrichina June 25, 2019 19:59

vgrichina reviewed Jun 25, 2019

View reviewed changes

Better example

5992aea

bowenwang1996 added 2 commits June 25, 2019 15:09

update PR number

757e927

fix json syntax

b449eaf

bowenwang1996 mentioned this pull request Jun 28, 2019

Contract metadata AssemblyScript/assemblyscript#697

Closed

bowenwang1996 mentioned this pull request Jun 28, 2019

Contract metadata nearprotocol/assemblyscript#38

Closed

eriktrautman mentioned this pull request Jul 5, 2019

Contract Metadata near/near-wallet#66

Open

5 tasks

Update json format

c178b4d

vgrichina reviewed Jul 10, 2019

View reviewed changes

text/0000-contract-metadata.md Show resolved Hide resolved

vgrichina reviewed Jul 10, 2019

View reviewed changes

text/0000-contract-metadata.md Outdated Show resolved Hide resolved

vgrichina reviewed Jul 10, 2019

View reviewed changes

text/0000-contract-metadata.md Outdated Show resolved Hide resolved

vgrichina reviewed Jul 10, 2019

View reviewed changes

text/0000-contract-metadata.md Outdated Show resolved Hide resolved

vgrichina reviewed Jul 10, 2019

View reviewed changes

text/0000-contract-metadata.md Outdated Show resolved Hide resolved

bowenwang1996 added 2 commits July 10, 2019 13:58

Add parameters in example

17951dc

change json format to use arrays

e994817

vgrichina reviewed Jul 11, 2019

View reviewed changes

MaksymZavershynskyi suggested changes Jul 23, 2019

View reviewed changes

janedegtiareva reviewed Jul 31, 2019

View reviewed changes

MaksymZavershynskyi mentioned this pull request Sep 2, 2019

Adding JS implementation near/borsh#5

Merged

New design

697f384

bowenwang1996 requested review from MaksymZavershynskyi and vgrichina September 17, 2019 16:10

MaksymZavershynskyi approved these changes Sep 18, 2019

View reviewed changes

vgrichina reviewed Sep 18, 2019

View reviewed changes

Update typedarray

301eeb3

bowenwang1996 mentioned this pull request Sep 21, 2019

Contract metadata nearprotocol/assemblyscript#71

Open

vgrichina mentioned this pull request Feb 3, 2020

Improve comments in template 01 nearprotocol/NEARStudio#247

Closed

chadoh mentioned this pull request Feb 26, 2020

Module System for Smart Contract and Frontend Integration near/devx#5

Open

MaksymZavershynskyi mentioned this pull request Feb 28, 2020

Metadata. Also add schema to each Borsh value near/near-sdk-rs#99

Merged

MaksymZavershynskyi closed this Mar 10, 2020

frol mentioned this pull request Feb 16, 2021

NEAR + Rust Contract Interface Parser near/bounties#42

Closed

4 tasks

MaximusHaximus mentioned this pull request Sep 13, 2021

feat: Multi Token Standard Contract [NEP] #245

Merged

bowenwang1996 mentioned this pull request Nov 8, 2021

[feature request] generate contract ABI on contract compilation near/nearcore#5166

Open

frol deleted the contract-metadata branch December 20, 2022 18:48

	will instead annotate the methods of a contract by decorators. We propose that view functions be annotated with the `@view` decorator
	will instead annotate the methods of a contract by decorators. We propose that view functions be annotated with the `@view` decorator in AssemblyScript (in Rust there is no need for additional decorators)

	To implement this NEP, we need to modify the binding generation procedure to generate a method called `metadata` that returns
	To implement this NEP, we need to modify the binding generation procedure in AssemblyScript compiler to generate a method called `metadata` that returns



	In Rust we would need to augment the procedural macro to inject the metadata method.

Basic contract metadata proposal #3

Basic contract metadata proposal #3

Conversation

bowenwang1996 commented Jun 25, 2019

vgrichina left a comment

Choose a reason for hiding this comment

bowenwang1996 commented Jun 25, 2019

DanielRX commented Jun 28, 2019 • edited Loading

bowenwang1996 commented Jun 28, 2019

DanielRX commented Jun 28, 2019

bowenwang1996 commented Jun 28, 2019 • edited Loading

DanielRX commented Jun 28, 2019

bowenwang1996 commented Jun 28, 2019 • edited Loading

vgrichina commented Jun 28, 2019

eriktrautman commented Jul 5, 2019

DanielRX commented Jul 7, 2019

bowenwang1996 commented Jul 7, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MaksymZavershynskyi Jul 25, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MaksymZavershynskyi commented Jul 29, 2019 • edited Loading

DanielRX commented Jul 30, 2019 • edited Loading

bowenwang1996 commented Jul 30, 2019

MaksymZavershynskyi commented Jul 31, 2019

janedegtiareva Jul 31, 2019 • edited Loading

Choose a reason for hiding this comment

DanielRX Aug 1, 2019 • edited Loading

Choose a reason for hiding this comment

vgrichina commented Jul 31, 2019

bowenwang1996 commented Jul 31, 2019

DanielRX commented Aug 1, 2019

ABI vs Metadata

Location of storage

DanielRX commented Aug 16, 2019

MaksymZavershynskyi commented Sep 3, 2019

MaksymZavershynskyi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lexfrl Nov 20, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bowenwang1996 commented Sep 24, 2019 • edited Loading

MaksymZavershynskyi commented Nov 19, 2019

lexfrl commented Nov 20, 2019

MaksymZavershynskyi commented Mar 10, 2020

DanielRX commented Jun 28, 2019 •

edited

Loading

bowenwang1996 commented Jun 28, 2019 •

edited

Loading

bowenwang1996 commented Jun 28, 2019 •

edited

Loading

MaksymZavershynskyi Jul 25, 2019 •

edited

Loading

MaksymZavershynskyi commented Jul 29, 2019 •

edited

Loading

DanielRX commented Jul 30, 2019 •

edited

Loading

janedegtiareva Jul 31, 2019 •

edited

Loading

DanielRX Aug 1, 2019 •

edited

Loading

lexfrl Nov 20, 2019 •

edited

Loading

bowenwang1996 commented Sep 24, 2019 •

edited

Loading