Abi - Refactor / Parser

[arboleya]

Summary

• Define ABI normalized type's tree
• Define public interface and points of interaction
• Document strategy to deal with future spec changes (via transpilation)
• Implement JSON parsing/transpilation for Spec V1

Final items

• An issue with generics in certain scenarios causing incorrect function signatures (@nedsalk)
• Ensuring that attributes get populated correctly (@petertonysmith94)

[petertonysmith94]

An initial draft for the proposed ABI public interface.

View in TS Playground

interface Abi {
    specVersion: string;
    encodingVersion: string;
    programType: string;

    functions: AbiFunction[];
    loggedTypes: AbiLoggedType[]
    messageTypes: AbiMessageType[]
    configurables: AbiConfigurable[]
}

interface AbiFunction {
    name: string;
    inputs: AbiTypeWithName[];
    output: AbiType;
    attributes?: AbiFunctionAttribute[];
}

interface AbiLoggedType extends AbiType {
    logId: string
};

interface AbiMessageType extends AbiType {
    messageId: string
};

interface AbiConfigurable extends AbiType {
    name: string;
    offset: number;
}

interface AbiType {
    // Concrete type ID
    typeId: string;
    // This will reference the metadata type
    // Fallback to concrete type when no metadata type is referenced (i.e. for built in types)
    type: string;
    components?: AbiTypeWithName[];
}

type AbiTypeWithName = AbiType & {
    name: string
};

type AbiFunctionAttribute =
  | StorageAttr
  | PayableAttr
  | TestAttr
  | InlineAttr
  | DocCommentAttr
  | DocAttr;

export interface PayableAttr {
  readonly name: 'payable';
}

export interface StorageAttr {
  readonly name: 'storage';
  readonly arguments: readonly ('read' | 'write')[];
}

export interface TestAttr {
  readonly name: 'test';
}
export interface InlineAttr {
  readonly name: 'inline';
  readonly arguments: 'never' | 'always';
}

export interface DocCommentAttr {
  readonly name: 'doc-comment';
  readonly arguments: string[];
}

export interface DocAttr {
  readonly name: 'doc';
}

[arboleya]

I have a gut feeling that we should probably keep concreteTypeId and metadaTypeId.

I wonder if abstracting this away will result in typeId containing different formats, which can be confusing.

Something to think about.

[petertonysmith94]

I have a gut feeling that we should probably keep concreteTypeId and metadaTypeId.

I wonder if abstracting this away will result in typeId containing different formats, which can be confusing.

I see your point - that could lead to confusion.

We planned for the typeId to always reference back to a concreteTypeId, therefore we're representing the ABI in a "resolved" state. @nedsalk we can talk about this and update accordingly.

[arboleya]

Oh, I see. Maybe I misinterpreted. I assumed it could be a hash or something else.

Anyway, I don't want to hold progress here, so take all my considerations with a grain of salt.

[petertonysmith94]

Closed in favour of:

• ABI coder + gen refactor #3650