{"id":18631,"date":"2026-03-25T04:25:42","date_gmt":"2026-03-25T04:25:42","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/25\/ethereum-research-update-ethereum-foundation-blog\/"},"modified":"2026-03-25T04:25:42","modified_gmt":"2026-03-25T04:25:42","slug":"ethereum-research-update-ethereum-foundation-blog","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/25\/ethereum-research-update-ethereum-foundation-blog\/","title":{"rendered":"Ethereum Research Update | Ethereum Foundation Blog"},"content":{"rendered":"<p> <br \/>\n<\/p>\n<div id=\"\">\n<p class=\"chakra-text css-gi02ar\">This week marks the completion\u00a0of our fourth hard fork, <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2016\/11\/18\/hard-fork-no-4-spurious-dragon\">Spurious Dragon<\/a>,\u00a0and the subsequent <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/www.reddit.com\/r\/ethereum\/comments\/5es5g4\/a_state_clearing_faq\/\">state clearing process<\/a>, the final steps in the two-hard-fork solution to the recent Ethereum <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2016\/09\/22\/transaction-spam-attack-next-steps\">denial of service attacks<\/a> that slowed down the network in September and October. Gas limits are in the process of being increased to 4 million as the network returns to normal, and will be increased further as\u00a0additional optimizations to clients are finished to allow quicker reading of state data.<\/p>\n<p class=\"chakra-text css-gi02ar\">In the midst of these events, we have seen great progress from the\u00a0C++ and Go development teams, including <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/www.reddit.com\/r\/ethereum\/comments\/5e5872\/browsersolidity_now_features_some_static_analysis\/\">improvements to Solidity tools<\/a> and the release of the <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2016\/11\/17\/whoa-geth-1-5\">Geth light client<\/a>, and the Parity, EthereumJ and other external development teams have continued pushing forward on their own with technologies such as Parity&#8217;s <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethcore\/parity\/wiki\/Warp-Sync\">warp sync<\/a>; many of these innovations have already made their way into the hands of the average user, and <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"http:\/\/status.im\">still others<\/a> are soon to come. At the same time, however, a large amount of quiet progress has been taking place on the research side, and while that progress has in many cases been rather blue-sky in nature and low-level protocol improvements necessarily take a while to make it into the main Ethereum network,\u00a0we expect that the results of the work\u00a0will start to bear fruit\u00a0very soon.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"metropolis\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"metropolis permalink\" href=\"#metropolis\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Metropolis<\/h3>\n<p>Metropolis is the next major planned hardfork for Ethereum. While Metropolis is not quite as ambitious as Serenity and will not include proof of stake, sharding or any other similarly large sweeping changes to how Ethereum works, it\u00a0is expected to include a series of small improvements to the protocol, which are altogether much more substantial than Homestead. Major improvements\u00a0include:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/www.reddit.com\/r\/ethereum\/comments\/5ab69v\/metropolis_protocol_change_proposal_highlight_for\/\">EIP 86 (account security abstraction)<\/a> &#8211; move the logic for verifying signatures and nonces into contracts, allowing developers to experiment with new signature schemes, privacy-preserving technologies and modifications to parts of the protocol without requiring further hard forks or support at the protocol level. Also allows contracts to pay for gas.<\/li>\n<li class=\"css-0\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/EIPs\/issues\/96\">EIP 96 (blockhash and state root changes)<\/a> &#8211; simplifies the protocol and client implementations, and allows for upgrades to light client and fast-syncing protocols that make them much more secure.<\/li>\n<li class=\"css-0\">Precompiled\/native contracts for elliptic curve operations and big integer arithmetic, allowing for applications based on ring signatures or RSA cryptography to be implemented efficiently<\/li>\n<li class=\"css-0\">Various improvements to efficiency that allow faster transaction processing<\/li>\n<\/ul>\n<p>Much of this work is part of a long-term plan\u00a0to move the protocol toward what\u00a0we call <em class=\"chakra-text css-0\">abstraction<\/em>. Essentially, instead of having complex protocol rules governing contract creation, transaction validation, mining and various other aspects of the system&#8217;s behavior, we\u00a0try to put as much of the Ethereum protocol&#8217;s logic as possible into the EVM itself, and have protocol logic simply be a set of contracts. This reduces client complexity, reduces the long-run risk of consensus failures, and makes hard forks easier and safer &#8211; potentially, a hard fork could be specified simply as a config file that changes the code\u00a0of a few contracts. By reducing the number of &#8220;moving parts&#8221; at the bottom level of the protocol in this way, we can greatly reduce Ethereum&#8217;s attack surface, and open up more parts of the protocol to user experimentation: for example, instead of the protocol upgrading to a new signature scheme all at the same time, users are free to experiment and implement their own.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"proof-of-stake-sharding-and-cryptoeconomics\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"proof of stake sharding and cryptoeconomics permalink\" href=\"#proof-of-stake-sharding-and-cryptoeconomics\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Proof of Stake, Sharding and Cryptoeconomics<\/h3>\n<p>Over the past year, research on proof of stake\u00a0and sharding has been quietly moving forward. The consensus algorithm that we have been working on, Casper, has gone through several iterations and proof-of-concept releases, each of which taught us important things about the combination of economics and decentralized consensus. <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/pyethereum\/tree\/serenity\">PoC release 2<\/a>\u00a0came at the start of this year, although that approach has now been abandoned as it has become obvious\u00a0that requiring every validator to send a message every block, or even every ten blocks, requires far too much overhead\u00a0to be sustainable. The more traditional chain-based\u00a0<a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"http:\/\/github.com\/ethereum\/pyethereum\/tree\/state_revamp\">PoC3<\/a>, as described in the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/docs.google.com\/document\/d\/1maFT3cpHvwn29gLvtY4WcQiI6kRbN_nbCf3JlgR3m_8\/edit#\">Mauve Paper<\/a>, has been more successful; although there are imperfections in how the incentives are structured, the flaws are much less serious in nature.<br \/>\n<img decoding=\"async\" src=\"https:\/\/www.initc3.org\/images\/events\/btcp_wksp\/1.jpg\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<p class=\"chakra-text css-gi02ar\">Myself, Vlad and many volunteers from\u00a0Ethereum research team came together at the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"http:\/\/www.cis.cornell.edu\/ic3-and-ethereal-holding-cryptocurrency-boot-camp-cis\">bootcamp at IC3<\/a> in July with university academics, Zcash developers and others to discuss proof of stake, sharding, privacy and other challenges, and substantial progress was made in bridging the gap between our approach to proof of stake\u00a0and that of others who have been working on similar problems. A newer and simpler version of Casper began to solidify, and myself and Vlad continued on two separate paths:\u00a0myself\u00a0aiming to create a simple proof of stake protocol that would provide desirable properties with as few changes from proof of work as possible, and Vlad taking a &#8220;correct-by-construction&#8221; approach to rebuild consensus from the ground up. Both were presented at Devcon2 in Shanghai in September, and that&#8217;s where we were at two weeks ago.<\/p>\n<p class=\"chakra-text css-gi02ar\">At the end of November, the research team (temporarily joined by Loi Luu, of <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eprint.iacr.org\/2015\/702.pdf\">validator&#8217;s dilemma<\/a> fame), along with some of our long-time volunteers and friends, came together for two weeks for a research workshop in Singapore, aiming to bring our thoughts together on various issues to do with Casper, scalability, consensus incentives and state size control.<\/p>\n<p class=\"chakra-text css-gi02ar\"><a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/images\/posts\/2016\/12\/IMG_20161201_151523.jpg\"><img decoding=\"async\" alt=\"dav\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/2016\/12\/IMG_20161201_151523.jpg\" class=\"chakra-image css-hw6q2r\"\/><\/a><\/p>\n<p class=\"chakra-text css-gi02ar\">A major topic of discussion was coming up with a rigorous and generalizable strategy for determining optimal incentives in consensus protocols &#8211; whether you&#8217;re creating a chain-based protocol, a scalable sharding protocol, or even an incentivized version of PBFT, can we come up\u00a0with a generalized way to correctly assign the right rewards and penalties to all participants, using only verifiable evidence that could be put into a blockchain as input, and in a way that would have optimal game-theoretic properties? We had some ideas; one\u00a0of them, when applied to proof of work as an experiment, immediately led to a new path toward solving\u00a0selfish mining attacks, and\u00a0has also proven extremely promising in addressing long-standing issues in proof of stake.<\/p>\n<p class=\"chakra-text css-gi02ar\">A key goal of our approach to cryptoeconomics is ensuring as much incentive-compatibility as possible even under a model with majority collusions: even if an attacker controls 90% of the network, is there a way to make sure that, if the attacker deviates from the protocol in any harmful way, the attacker loses money? At least in some cases, such as short-range forks,\u00a0the answer seems to be yes. In other cases, such as censorship, achieving this goal\u00a0is much harder.<\/p>\n<p class=\"chakra-text css-gi02ar\">A\u00a0second goal is\u00a0bounding &#8220;griefing factors&#8221; &#8211; that is, ensuring that there is no way for an attacker to cause other players to lose money without losing close to the same amount of money themselves. A third goal is\u00a0ensuring that the protocol continues to work as well as possible under other kinds of extreme conditions: for example, what if 60% of the validator nodes\u00a0drop offline simultaneously? Traditional consensus protocols\u00a0such as PBFT, and proof of stake protocols inspired by such approaches,\u00a0simply halt in this case; our goal with Casper is\u00a0for the chain to continue, and even if the chain can&#8217;t provide all of the guarantees that it normally does under such conditions the protocol should still try to do as much as it can.<\/p>\n<p class=\"chakra-text css-gi02ar\">One of the main beneficial results of the workshop\u00a0was bridging the gap\u00a0between my current &#8220;exponential ramp-up&#8221; approach to transaction\/block\u00a0finality in\u00a0Casper, which rewards validators for making bets with increasing confidence and penalizes them if their bets are wrong,\u00a0and Vlad&#8217;s &#8220;correct-by-construction&#8221; approach, which emphasizes penalizing validators only if they equivocate (ie. sign two incompatible messages). At the end of the workshop, we began to work together on strategies to combine the best of both approaches, and we have already started to use\u00a0these insights to improve the Casper protocol.<\/p>\n<p class=\"chakra-text css-gi02ar\">In the meantime,\u00a0I have written some documents and FAQs that detail the current state of thinking regarding proof of stake, sharding and Casper to help bring anyone interested\u00a0up to speed:<\/p>\n<p class=\"chakra-text css-gi02ar\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/Proof-of-Stake-FAQ\"\/><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/Proof-of-Stake-FAQ\">https:\/\/github.com\/ethereum\/wiki\/wiki\/Proof-of-Stake-FAQ<\/a><\/p>\n<p class=\"chakra-text css-gi02ar\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/Sharding-FAQ\"\/><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/Sharding-FAQ\">https:\/\/github.com\/ethereum\/wiki\/wiki\/Sharding-FAQ<\/a><\/p>\n<p class=\"chakra-text css-gi02ar\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/docs.google.com\/document\/d\/1maFT3cpHvwn29gLvtY4WcQiI6kRbN_nbCf3JlgR3m_8\"\/><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/docs.google.com\/document\/d\/1maFT3cpHvwn29gLvtY4WcQiI6kRbN_nbCf3JlgR3m_8\">https:\/\/docs.google.com\/document\/d\/1maFT3cpHvwn29gLvtY4WcQiI6kRbN_nbCf3JlgR3m_8<\/a>\u00a0(Mauve Paper; now slightly out of date but will be updated soon)<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"state-size-control\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"state size control permalink\" href=\"#state-size-control\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>State size control<\/h3>\n<p>Another important area of protocol design\u00a0is state size control &#8211; that is, how to we reduce the amount of state information that full nodes need to keep track of? Right now, the state is about a gigabyte in size (the rest of the data that a geth or parity node currently stores is the transaction history; this data can theoretically be pruned once there is a robust light-client protocol for fetching it), and we saw already how protocol usability degrades in several ways if it grows much larger; additionally, sharding becomes much more difficult as sharded blockchains require nodes to be able to quickly download parts of the state as part of the process of serving as validators.<\/p>\n<p class=\"chakra-text css-gi02ar\">Some proposals that have been raised have to do with <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/EIPs\/issues\/168\">deleting old non-contract\u00a0accounts<\/a> with not enough ether to send a transaction, and doing so safely <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"http:\/\/github.com\/ethereum\/EIPs\/issues\/169\">so as to prevent replay attacks<\/a>. Other proposals involve simply making it much more expensive to create new accounts or store data, and doing so in a way that is more decoupled from\u00a0the way that we pay for other kinds of costs inside the EVM. Still other proposals include putting time limits on how long contracts can last, and charging more to create accounts or contracts with longer time limits (the time limits here would be generous; it would still be affordable\u00a0to create a contract that lasts several years). There is currently an ongoing debate in the developer community about the best way to achieve the goal of keeping state size small, while at the same time keeping the core protocol maximally user and developer-friendly.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"miscellanea\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"miscellanea permalink\" href=\"#miscellanea\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Miscellanea<\/h3>\n<p>Other areas of low-level-protocol improvement\u00a0on the horizon\u00a0include:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Several <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/cpp-ethereum\/issues\/3404\">&#8220;EVM 1.5&#8221; proposals<\/a> that make the EVM more friendly to static analysis, facilitating compatibility with WASM<\/li>\n<li class=\"css-0\">Integration of zero knowledge proofs, likely\u00a0through either (i) an explicit ZKP opcode\/native contract, or (ii) an opcode or native contract for the key computationally intensive ingredients in ZKPs, particularly elliptic curve pairing computations<\/li>\n<li class=\"css-0\">Further degrees of abstraction and protocol simplification<\/li>\n<\/ul>\n<p>Expect more detailed documents and conversations on all of these topics in the months to come, especially as work on turning the Casper specification into a viable proof of concept release that could run a testnet continues to move forward.<\/p><\/div>\n<p><br \/>\n<br \/><a href=\"https:\/\/blog.ethereum.org\/en\/2016\/12\/04\/ethereum-research-update\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week marks the completion\u00a0of our fourth hard fork, Spurious Dragon,\u00a0and the subsequent state clearing process, the final steps in the two-hard-fork solution to the recent Ethereum denial of service attacks that slowed down the network in September and October. Gas limits are in the process of being increased to 4 million as the network [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":18498,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[24],"tags":[],"kronos_expire_date":[],"class_list":["post-18631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ethereum"],"_links":{"self":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18631","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/comments?post=18631"}],"version-history":[{"count":0,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18631\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media\/18498"}],"wp:attachment":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media?parent=18631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/categories?post=18631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/tags?post=18631"},{"taxonomy":"kronos_expire_date","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/kronos_expire_date?post=18631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}