You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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!
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.
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 asvoteData
,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 theeth
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
The text was updated successfully, but these errors were encountered: