Skip to content
This repository was archived by the owner on Jul 5, 2024. It is now read-only.

Add spec for CALLER opcode#90

Merged
ed255 merged 1 commit into
masterfrom
feature/opcode-caller
Jan 14, 2022
Merged

Add spec for CALLER opcode#90
ed255 merged 1 commit into
masterfrom
feature/opcode-caller

Conversation

@ed255
Copy link
Copy Markdown
Contributor

@ed255 ed255 commented Jan 13, 2022

I have followed the pattern from #83 but using the CallContext in the rw_table instead of the Block table for the value lookup.

Related issue: #86


I've added two questions for doubts I had:

    # QUESTION: Where is it checked that address raw data is 160 bit length (20
    # bytes)?
    # QUESTION: Which is better of the two options?
    # a. rlc_decode(stack_value) == call_context_lookup()
    # b. stack_value == rlc_encode(call_context_lookup())

@ed255 ed255 added the opcode label Jan 13, 2022
@ed255 ed255 requested review from CPerezz and han0110 January 13, 2022 15:02
@ed255 ed255 force-pushed the feature/opcode-caller branch from c27b6e7 to fd68f5f Compare January 13, 2022 15:17
@ed255 ed255 mentioned this pull request Jan 13, 2022
5 tasks
@han0110
Copy link
Copy Markdown
Contributor

han0110 commented Jan 14, 2022

Where is it checked that address raw data is 160 bit length (20 bytes)

The address from call context will always be verified by the step that triggers the call (e.g. BeginTx, *CALL*, CREATE*), and because rw_table guarantee read/write consistency, so we don't need to double-check if it's a valid address.

Which is better of the two options?

Option b. sounds better IMHO, since we read the call context first, and do a base conversion (from 256 to r), then push to stack. But both work for me.

Copy link
Copy Markdown
Contributor

@CPerezz CPerezz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo applying @han0110 's replies.

Comment thread specs/opcode/33CALLER.md Outdated
Copy link
Copy Markdown
Contributor

@han0110 han0110 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@ed255 ed255 force-pushed the feature/opcode-caller branch from fd68f5f to 2740c8e Compare January 14, 2022 14:24
@ed255 ed255 force-pushed the feature/opcode-caller branch from 2740c8e to 42d01e1 Compare January 14, 2022 14:25
@ed255
Copy link
Copy Markdown
Contributor Author

ed255 commented Jan 14, 2022

Option b. sounds better IMHO, since we read the call context first, and do a base conversion (from 256 to r), then push to stack. But both work for me.

I've updated the spec to follow option b, and removed the notes about checking the address byte length.

@ed255 ed255 merged commit ffcc929 into master Jan 14, 2022
@ed255 ed255 deleted the feature/opcode-caller branch March 23, 2022 12:27
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants