Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abi - Refactor / Parser #3030

Open
4 tasks
arboleya opened this issue Aug 25, 2024 · 4 comments · May be fixed by #3085
Open
4 tasks

Abi - Refactor / Parser #3030

arboleya opened this issue Aug 25, 2024 · 4 comments · May be fixed by #3085
Assignees
Labels
chore Issue is a chore feat Issue is a feature

Comments

@arboleya
Copy link
Member

  • 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
@arboleya arboleya added feat Issue is a feature chore Issue is a chore labels Aug 25, 2024
@arboleya arboleya added this to the Caterpillar v1 milestone Aug 25, 2024
@petertonysmith94
Copy link
Contributor

petertonysmith94 commented Sep 2, 2024

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
Copy link
Member Author

arboleya commented Sep 2, 2024

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 petertonysmith94 linked a pull request Sep 3, 2024 that will close this issue
4 tasks
@petertonysmith94
Copy link
Contributor

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
Copy link
Member Author

arboleya commented Sep 3, 2024

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.

@arboleya arboleya removed this from the Caterpillar v1 milestone Sep 7, 2024
@arboleya arboleya added the temp:notion label Sep 8, 2024 — with Linear
@arboleya arboleya added the temp-linear label Sep 8, 2024 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Issue is a chore feat Issue is a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants