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

[Interface] Need refinement to eth namespace #1858

Open
hyunsooda opened this issue Jun 7, 2023 · 3 comments
Open

[Interface] Need refinement to eth namespace #1858

hyunsooda opened this issue Jun 7, 2023 · 3 comments
Assignees
Labels
enhancement New feature or enhancement

Comments

@hyunsooda
Copy link
Contributor

Is your request related to a problem? Please describe.

The Caver, provided by the Official Klaytn team, has been utilized to query certain values from live nodes. However, this approach may not be the most suitable for hardhat-based projects.

Currently, the eth namespace implementation does not provide access to important data such as voteData, governanceData, extraData, and so on. Ideally, the returned data should include all the values specific to the Klaytn network, while additional values from the Ethereum network can be included as well in the eth namespace call function.

I refrained from creating PR regarding this matter because I am unaware of the decision-making process behind the decision to conceal them.

Describe the solution you'd like
Ideally, the returned data should include all the values specific to the Klaytn network, while additional values from the Ethereum network can be included as well in the eth namespace call function.

Describe alternatives you've considered
None

Additional context
None

@exalate-issue-sync
Copy link

Exalate commented: Issue Created by: hyunsooda

@aidan-kwon
Copy link
Member

Not returning Klaytn-specific data in eth is an intended behavior. As it is described in Klaytn Docs, the purpose of eth namespace is to provide compatibility with Ethereum SDK and tools such as ethers.js, web3.js, and hardhat. Klaytn-specific data causes errors to parse API returning data in Ethereum SDK and tools, so we omit or simplify them.

If you have any good ideas that can provide Ethereum ecosystem tools' compatibility as well as Klaytn-specific data, please share us. thanks!

@aidan-kwon aidan-kwon self-assigned this Jun 7, 2023
@hyunsooda
Copy link
Contributor Author

hyunsooda commented Jun 8, 2023

I wished to the code below be work, but some of fields were not present.

let provider = new ethers.providers.WebSocketProvider("ws://127.0.0.1:8552");
provider._subscribe('newHeads', ["newHeads"], block => {
   console.log(block) // trimmed `extraData`, `governanceData`, etc.
})

Altenatively, this code works with an additional RPC call.

let provider = new ethers.providers.WebSocketProvider("ws://127.0.0.1:8552");
provider.on('block', async function (n) {
  h = await provider.send('klay_getHeaderByNumber', [n]);
  console.log(h) 
})

Klaytn-specific data causes errors to parse API returning data in Ethereum SDK and tools, so we omit or simplify them.

It is unusual for SDKs to generate errors when unexpected fields are encountered. In an ideal scenario, the SDK should simply return the queried data without raising errors.

To identify their behavior, I made modifications to the binary so that it returns the same values within the eth namespace. Upon testing, it was confirmed that the modified binary successfully functions as intended.

Furthermore, it is worth noting that the current output fields in the eth namespace differ from those in the existing geth implementation. Notably, the fields omitted in the current implementation are baseFeePerGas and transactions.

@sjnam sjnam added enhancement New feature or enhancement and removed Github labels Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants