Merge branch 'master' into update-asset-cert

blog/news-and-updates/2025-01-08-update.mdx

@@ -2,7 +2,7 @@
 title: Developer weekly update January 8, 2025
 description: To kick off the year, we have some exiting updates regarding the Motoko base library and ICP Ninja, plus a community conversation regarding ICRC-99 and ckNFTs.
 tags: [Devs]
-image: /img/blog/dev-update-blog-jan-9.jpg
+image: /img/blog/dev-update-blog-jan-8.jpg
 ---
 
 # Developer weekly update January 8, 2025

blog/news-and-updates/2025-01-15-update.mdx

@@ -0,0 +1,61 @@
+---
+title: Developer weekly update January 15, 2025
+description: This week, we have a roadmap milestone release, a few new tooling releases, and an important announcement about ETH Denver 2025.
+tags: [Devs]
+image: /img/blog/dev-update-blog-jan-15.jpg
+---
+
+# Developer weekly update January 15, 2025
+
+![January 15, 2025](../../static/img/blog/dev-update-blog-jan-15.jpg)
+
+Hello developers, and welcome to this week's developer weekly update! This week, we have a roadmap milestone release, a few new tooling releases, and an important announcement about ETH Denver 2025. Let's get started!
+
+## Plasma release: Governance milestone
+
+The first milestone of 2025 has been achieved! The Plasma milestone includes several new features on the NNS and new proposal types for deployed SNSes. Features in this milestone include:
+
+- Neurons table design: New design for viewing neuron information.
+
+- Actionable proposals: Clearly see which proposals you can still vote on.
+
+- SNS name and logo change proposals: SNSes can now change their name and logo via proposal.
+
+- Canister-controlled neurons: New functionality for canisters to control a neuron.
+
+- Periodic confirmation: Facilitating active governance participation by periodically asking neurons to confirm their following configuration.
+
+- ICRC-1 token imports: Import any token that supports the ICRC-1 standard to the NNS.
+
+- Neuron visibility settings: Neurons can now be public or private. Public neurons can decide which information they expose about themselves.
+
+- Improved SNS upgrades.
+
+You can learn more about this milestone on the [ICP roadmap](https://internetcomputer.org/roadmap#Governance%20&%20Tokenomics-Plasma) or check out the [milestone release livestream](https://www.youtube.com/watch?v=W01GOBBVY1w).
+
+## Tooling releases
+
+A few new tooling releases are available:
+
+- `ic-repl` v0.7.7: https://github.com/dfinity/ic-repl/releases/tag/0.7.7
+
+- Candid v0.10.12: https://github.com/dfinity/candid
+
+- Internet Identity: https://github.com/dfinity/internet-identity/releases/tag/release-2025-01-10
+
+- `ic-wasm` v0.9.3: https://github.com/dfinity/ic-wasm/releases/tag/0.9.3
+
+
+## ETH Denver 2025
+
+ICP will be at [ETH Denver 2025](https://www.ethdenver.com/) and would love to see you there! For our developer ecosystem, we're offering some exciting opportunities to showcase your project during the event, including:
+
+- Pitch opportunities: Demo your project at different side events that are sponsored by ICP.
+
+- Booth space: Chat with event attendees at the ICP booth, give live demos, or pass out merch.
+
+If you're interested in participating in either opportunity, fill out the [Google Form](https://docs.google.com/forms/d/e/1FAIpQLSdqWNBRiy-rW2uLt7lhW9am5a6NWidT956oBLrUjkV9gEOTJw/viewform) to let us know!
+
+That'll wrap up this week. Tune back in next week for more developer updates!
+
+-DFINITY

docs/developer-docs/backend/solidity/index.mdx

@@ -14,7 +14,5 @@ Solidity is an object-oriented, high-level language for implementing smart contr
 
 The Bitfinity EVM is an EVM implementation based on [REVM](https://github.com/bluealloy/revm). It provides an RPC interface that is compatible with the Ethereum JSON-RPC API. This means that existing Ethereum tools and libraries, such as [MetaMask](https://metamask.io/), [Hardhat](https://hardhat.org/) and [Foundry](https://getfoundry.sh/), can be used to interact with the EVM and provide a similar developer and user experience.
 
-The Bitfinity EVM is currently at Testnet stage, and is not yet ready for production use. It is available for experimentation and testing purposes only.
-
 For more information, please refer to the official [Bitfinity EVM documentation](https://docs.bitfinity.network/).
 

docs/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-confirm-following.mdx

@@ -0,0 +1,52 @@
+---
+keywords: [beginner, governance, tutorial, nns]
+---
+
+import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
+import '/src/components/CenterImages/center.scss';
+
+# Periodic Neuron Following Confirmation
+
+<MarkdownChipRow labels={["Beginner", "Governance", "Tutorial"]} />
+
+<div class="text--center">
+<p> </p>
+</div>
+
+
+The main idea of periodic confirmation of following is that in order to get rewards, governance participants have to remain active voters and regularly confirm their following settings. Neurons who set following once or were created with default following and then never interact with the NNS again get lower, adjusted voting rewards. To find more information about the feature and community discussions about it, please see the [blog post](https://medium.com/dfinity/onchain-governance-improvement-periodic-confirmation-of-following-4c8fd73f578d), [forum discussion](https://forum.dfinity.org/t/periodic-confirmation-design/34215), and the adopted [motion proposal](https://dashboard.internetcomputer.org/proposal/132411).
+
+## Maximizing voting rewards
+
+In order to keep your voting power and thus keep getting voting rewards, you need to take at least one of the following three actions once every 6 months for each of your neurons:
+1. [Vote directly](https://internetcomputer.org/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-voting-on-proposals)
+2. [Set or edit following](https://internetcomputer.org/docs/current/developer-docs/daos/nns/using-the-nns-dapp/nns-dapp-following-other-neurons)
+3. Confirm following
+
+:::info
+Note that if you're following other neurons, you will only receive the maximum voting rewards if the neurons you follow vote on all proposals. To see how neurons vote, visit [vpGeek](https://f2djv-5aaaa-aaaah-qdbea-cai.raw.icp0.io/knownNeurons).
+:::
+
+## How to confirm neuron following
+
+- **Step 1:** Sign into the [NNS dapp](https://nns.ic0.app/), navigate to **Neuron Staking** and click on **Internet Computer**. If you have neurons that are within 30 days of missing rewards, you will see a banner with a warning.
+
+![NNS Periodic Confirmation 1](../../_attachments/periodic-1.webp)
+
+- **Step 2:** Click on **Confirm Following**, and you will be prompted with a modal window. Here, you can review following for all of your neurons. If you agree with your current following setup, you can click **Confirm Following** to apply to all neurons. Alternatively, clicking any of them will bring you to the **Neuron Details** page, where you can edit (or confirm) your following for a single neuron.
+
+![NNS Periodic Confirmation 1](../../_attachments/periodic-2.webp)
+
+Once you confirmed following on all of your neurons, the warning will disappear, and the neuron inactivity timer will be reset to 6 months.
+
+Alternatively, you can:
+
+- **Step 3**: Navigate to **Neuron Staking** and click on **Internet Computer**. Select any of your neurons, which will bring you to the **Neuron Details** page.
+
+![NNS Import Tokens 3](../../_attachments/periodic-3.webp)
+
+- **Step 4**: Click on **Confirm Following**, which will open up a modal window. Here, you can review and confirm your following. Make sure you still agree with the decision you made in the past. Otherwise, you can edit your following on this page.
+
+![NNS Import Tokens 4](../../_attachments/periodic-4.webp)
+
+Note that alternatively, you can vote on a proposal, which will reset the neuron inactivity timer for all neurons that voted, or edit your following.

docs/developer-docs/developer-tools/on-chain/cdks.mdx

@@ -45,8 +45,6 @@ Kybra is a CDK developed by [Demergent Labs](https://github.com/demergent-labs)
 
 The Bitfinity EVM is an experimental EVM implementation that provides an RPC interface compatible with the Ethereum JSON-RPC API. While this is not a traditional CDK, it does provide the ability for existing Ethereum tools and libraries to be used to develop Solidity canisters on ICP.
 
-The Bitfinity EVM is in the early stages of development and should not be used for production development.
-
 ### Resources
 
 - [Bitfinity EVM documentation](https://docs.bitfinity.network/).

docs/developer-docs/security/security-best-practices/inter-canister-calls.mdx

@@ -20,7 +20,7 @@ This is also explained in the [community conversation on security best practices
 
 ### Security concern
 
-Traps and panics roll back the canister state, as described in Property 5 above. So any state change followed by a trap or panic can be risky. This is an important concern when inter-canister calls are made. If a trap occurs after an await to an inter-canister call, then the state is reverted to the snapshot before the inter-canister call’s callback invocation, and not to the state before the entire call.
+Traps and panics roll back the canister state, as described in [Property 5](/docs/current/references/message-execution-properties#message-execution-properties). So any state change followed by a trap or panic can be risky. This is an important concern when inter-canister calls are made. If a trap occurs after an await to an inter-canister call, then the state is reverted to the snapshot before the inter-canister call’s callback invocation, and not to the state before the entire call.
 
 More precisely, suppose some state changes are applied and then an inter-canister call is issued. Also, assume that these state changes leave the canister in an inconsistent state, and that state is only made consistent again in the callback. Now if there is a trap in the callback, this leaves the canister in an inconsistent state.
 
@@ -135,11 +135,11 @@ GoldDAO's GLDT-swap has an implementation of journaling. In their case, the jour
 
 ### Security concern
 
-As described in the [properties of message executions on ICP](/docs/current/references/message-execution-properties), messages (but not entire calls) are processed atomically. In particular, as described in Property 4 in that document, messages from interleaving calls do not have a reliable execution ordering. Thus, the state of the canister (and other canisters) may change between the time an inter-canister call is started and the time when it returns, which may lead to issues if not handled correctly. These issues are generally called 'Reentrancy bugs' (see the [Ethereum best practices on reentrancy](https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/)). Note however that the messaging guarantees, and thus the bugs, on ICP are different from Ethereum.
+As described in the [properties of message executions on ICP](/docs/current/references/message-execution-properties), messages (but not entire calls) are processed atomically. In particular, as described in [Property 4](/docs/current/references/message-execution-properties#message-execution-properties) in that document, messages from interleaving calls do not have a reliable execution ordering. Thus, the state of the canister (and other canisters) may change between the time an inter-canister call is started and the time when it returns, which may lead to issues if not handled correctly. These issues are generally called 'Reentrancy bugs' (see the [Ethereum best practices on reentrancy](https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/)). Note however that the messaging guarantees, and thus the bugs, on ICP are different from Ethereum.
 
 Here are two concrete and somewhat similar types of bugs to illustrate potential reentrancy security issues:
 
-- **Time-of-check time-of-use issues:** These occur when some condition on global state is checked before an inter-canister call, and then wrongly assuming the condition still holds when the call returns. For example, one might check if there is sufficient balance on some account, then issue an inter-canister call and finally make a transfer as part of the callback message. When the second inter-canister call starts, it is possible that the condition which was checked initially no longer holds, because other ledger transfers may have happened before the callback of the first call is executed (see also Property 4 above).
+- **Time-of-check time-of-use issues:** These occur when some condition on global state is checked before an inter-canister call, and then wrongly assuming the condition still holds when the call returns. For example, one might check if there is sufficient balance on some account, then issue an inter-canister call and finally make a transfer as part of the callback message. When the second inter-canister call starts, it is possible that the condition which was checked initially no longer holds, because other ledger transfers may have happened before the callback of the first call is executed (see also [Property 4](/docs/current/references/message-execution-properties#message-execution-properties)).
 
 - **Double-spending issues.**: Such issues occur when a transfer is issued twice, often because of unfavorable message scheduling. For example, suppose you check if a caller is eligible for a refund and if so, transfer some refund amount to them. When the refund ledger call returns successfully, you set a flag in the canister storage indicating that the caller has been refunded. This is vulnerable to double-spending because the refund method can be called twice by the caller in parallel, in which case it is possible that the messages before issuing the transfer (including the eligibility check) are scheduled before both callbacks. A detailed explanation of this issue can be found in the [community conversation on security best practices](https://www.youtube.com/watch?v=PneRzDmf_Xw&list=PLuhDt1vhGcrez-f3I0_hvbwGZHZzkZ7Ng&index=2&t=4s).
 
@@ -309,7 +309,7 @@ Finally, note that the same guard can be used in several methods to restrict par
 
 ### Security concern
 
-As stated by the Property 6 above, inter-canister calls can fail in which case they result in a **reject**. See [reject codes](/docs/current/references/ic-interface-spec#reject-codes) for more detail. The caller must correctly deal with the reject cases, as they can happen in normal operation, because of insufficient cycles on the sender or receiver side, or because some data structures like message queues are full.
+As stated by the [Property 6](/docs/current/references/message-execution-properties#message-execution-properties), inter-canister calls can fail in which case they result in a **reject**. See [reject codes](/docs/current/references/ic-interface-spec#reject-codes) for more detail. The caller must correctly deal with the reject cases, as they can happen in normal operation, because of insufficient cycles on the sender or receiver side, or because some data structures like message queues are full.
 
 Not handling the error cases correctly is risky: For example, if a ledger transfer results in an error, the callback dealing with that error must interpret it correctly. That is, it must be interpreted as "the transfer did not happen".