比特币是去中心化的和开源的，这意味着没有集中的权限来决定协议升级，以及任何人都可以自由地使用、修正和变更代码。这并不意味着比特币是无政府主义式治理的。相反，比特币遵循开源软件传统的协作治理模式，比特币用于更新其软件的过程，大量借鉴了部分阿帕网（ARPANET）在 1969 年创建的请求评议（Request for Comments）格式。
比特币既是一种技术也是一种货币。虽然比特币交易是不可篡改的并且永久保留在区块链上，但其基础协议正在被不断改进和升级。仅仅因为没有一个控制这种发展的中心机构，并不意味着基础协议也年复一年地保持不变。
通过比特币改进提案（BIPs）提出并执行对比特币协议的升级。 BIP 为贡献者提供了标准化流程，以便为协议提出新想法、测试这些想法以及对其进行同行评审。这种制衡系统旨在允许对协议进行持续创新，同时确保通过共识和协作实现改进。
比特币代码最初完全是由中本聪编写的，用于验证像 BTC 这样的分布式点对点货币实际上是否是可行的。令许多人惊讶的是，BTC 发挥了应有的作用。
但这意味着在比特币的早期阶段，是没有协作和开发协议的标准。中本聪自己完成了大部分原始代码的撰写，以及之后的更新和技术改进。他征求了密码学邮件列表的反馈，这是一个密码学家的互联网电子邮件列表，并且他最终创建了 BitcoinTalk 论坛——一个致力于比特币的网络论坛。
然而，最终，协议的控制权掌握在中本聪手中。当有人向中本聪报告了一个比特币代码库中的漏洞使任何人都可以花费其他人的比特币时，中本聪推动了比特币协议的更新，并告诉网络上的每个人升级他们的客户端，而没有解释原因。
为了生存，比特币需要开发流程来减少对某一单独个体的依赖，转而依靠更大的开发者社区。 中本聪从比特币项目的退出实现了这一点。
在早年，中本聪已经获得了 Gavin Andresen 的帮助，Gavin Andresen 是一位积极参与社区活动的开发人员。当中本聪宣布他将于 2011 年离开该项目时，他将手中的缰绳转交给了 Andresen。 Andresen 不想完全靠自己对代码承担全部责任，因此他征求了其他四位开发人员的帮助：Pieter Wuille、Wladimir van der Laan、Gregory Maxwell 和 Jeff Garzik。这些开发人员被称为“比特币核心开发人员”，因为他们负责管理着主要的比特币核心客户端执行的开发。
从历史上看，比特币核心开发人员一直负责比特币协议的大部分开发工作。他们维护比特币的代码库，是唯一能够将实时代码推送到比特币核心客户端的人。虽然这些年来有数百人为比特币贡献了代码，但只有十几人曾经拥有对代码库的访问权限。
虽然这导致人们认为比特币核心开发人员对协议的开发具有专制般的影响力，但事实并非如此。核心开发人员参与的是粗略共识的过程，以确定最终包含在决策内的内容。
维护者——拥有访问比特币核心 Github 代码仓库的开发人员——将考虑是否有补丁：
符合项目的一般原则 符合最低标准 符合贡献者的普遍共识。 比特币核心的贡献者 Jameson Lopp 指出：
虽然维护者组织在技术上有可能发动劫持 GitHub 代码仓库、删改存在异议的开发人员甚至维持“比特币核心”品牌名称的“政变”，但其结果将会导致比特币核心将不再是开发焦点。不同意维护者行为的开发人员只需将代码分叉并将其工作转移到不同的代码仓库，而比特币核心维护者对其没有管理员权限。
尽管如此，随着比特币网络多年来的发展，其信徒们的争论一直围绕在扩展、技术改进以及更多的进展，加深了比特币核心对协议实施了绝对控制的看法。比特币核心开发者对开发的影响之深，甚至导致比特币现金社区将原始的比特币区块链称之为“比特币核心”（Bitcoin Core）。
比特币改进提案流程的建立是为了围绕比特币的开发过程展开讨论，并让更多社区成员更易理解。它旨在使核心开发者已经使用的许多流程正式化。
比特币改进提案（BIP）是一项提议改进比特币协议的标准，由 Amir Taaki 于 2011 年在 BIP 0001 中提出，并由 Luke Dash Jr. 在 BIP 0002 中对其进行了扩展。
BIP 流程严重依赖于 Python 改进提案（Python Enhancement Proposal ，PEP 0001），甚至直接复制了其中的一些文本。它还提到了一个名为“On Consensus and Humming in the IETF”的文件，这是一套来自互联网工程任务组的开源协作原则。
BIP 流程的目标是允许任何人对比特币协议提出改进的想法，但在实施任何可能威胁到网络稳定性的代码之前，还要彻底审查这些想法的安全性和可行性。
该流程旨在让社区围绕提出的想法建立粗略的共识。 P. Resnick 将粗略共识定义如下：
粗略的共识已经在很多方面被定义过了：一个简单的版本是，粗略共识意味着强烈提出的反对意见必须经历辩论，直到大多数人都认为这些反对意见是错误的。
赋予社区能够提出想法、同行评审想法以及围绕它们达成共识的能力，对于像比特币这样没有领导者的分布式协议的发展至关重要。 自 BIP 流程建立以来，已经有 191 个 BIP Github 代码仓库贡献者。
有三种不同类型的 BIP：
标准追踪 BIP 提议了对比特币进行更改，包括更改网络协议、区块或交易有效性规则，或影响使用比特币的应用程序互操作性的任何更改。 信息 BIP 描述了协议中的设计问题或向社区提供信息。他们不建议为协议执行新的功能。 流程 BIP：提出围绕开发比特币的流程，或建议对流程进行更改。它们不直接影响比特币的代码库，但它们可能包括新程序、开发决策的变化或者比特币开发中使用工具的变化。 每个 BIP 必须经过几个不同的阶段才能实施。这是 BIP 001 中描述该工作流程的图像：
要实施到话，BIP 必须从草案阶段，到提议阶段，再到最终阶段。
草案（Draft）：BIP 作为草案提交给比特币开发邮件列表和 BIP Github 代码仓库。 提议（Proposed）：BIP 包括了一个含有部署 BIP 计划的工作执行方案。 最终（ Final）：BIP 符合现实世界的采用标准。且必须客观地验证这一点。 在此过程中，BIP 可以被社区拒绝、撤回或替换：
延期：BIP 的提交人可以在没有取得任何进展的情况下将其状态更改为延期。 撤回：BIP 的提交人也可以选择完全撤回 BIP。 被拒绝：如果三年内没有取得任何进展，任何人都可以请求将 BIP 移至被拒绝状态。 替换：如果先前的最终 BIP 变得无关紧要，则将其标记为已替换。例如，这种情况可能发生在，当一个在软分叉中实施的 BIP，而在三个月之后却被硬分叉倾覆的时候。 下面，我们将详细介绍此过程的两个主要阶段。
草案阶段的目标是将关于比特币的新想法格式化为标准化的 BIP，并尽快开始征求社区的反馈意见。
BIP 的提交人负责审查社区的想法，以评估该想法的可行性，并围绕它建立社区共识。他们应该与比特币开发者邮件列表以及 Bitcoin Talk 技术论坛分享想法。这有助于确定该想法是否原创、可行并保证了一个独立的 BIP。 提交人创建了一份 BIP 草案，并将其提交给比特币开发邮件列表进行讨论。这允许作者以 BIP 的标准格式呈现该想法并处理来自社区的其他任何问题。 在讨论之后，提交人将提议作为拉取请求提交给 BIP github 代码仓库。 BIP 代码仓库的编辑器为提案分配一个数字，根据类型对其进行标记，然后将其添加到代码存储库中。 BIP 编辑只有在不符合特定标准的情况下才能拒绝 BIP——例如，如果提出的更新情况不清晰，或者在技术上不合理。 为了推动草案进入提议，当提交人处理完社区中存在的任何异议时，BIP 会认为草案已经完成并且其中包含了提议的工作执行方案。 草案阶段旨在允许提交者征求社区的反馈意见并修改 BIP 以处理在此阶段提出的任何异议。一旦完成草案阶段并提交 BIP 后，它将被移至提议阶段。
当 BIP 的状态更改为提议时，它现在已准备好从讨论状态转移到实际比特币协议中的部署。为此，每个 BIP 都需要包含具体标准，概述如何客观地建立起现实世界的采用。
通常，这意味着需要通过软分叉或硬分叉将 BIP 执行到代码中。
软分叉引入了向后兼容的协议更改，这意味着运行最新版本软件的节点仍然与运行旧版本的节点兼容。
与软分叉不同的是，硬叉引入了不向后兼容的协议更改。这意味着如果大量节点不升级包含新软件的客户端，则链会被一分为二，就像比特币现金（Bitcoin Cash）硬分叉一样。因此，硬分叉是比 BIP 实施风险更高的方式。
BIP 002 为确认如何通过软分叉或硬分叉最终确定一个 BIP，提供了一些指导原则：
一个软分叉 BIP 需要通过“明显处于多数的矿工”来激活。建立此“多数”的建议指南是说，95％的节点通过升级包含 BIP 的新软件来批准它。软分叉所激活的 BIP 必须包含一个 BIP 将在网络上的活跃时间。
另一方面，硬分叉 BIP 需要整个社区采用。网络上的节点需要升级到包含了 BIP 的客户端软件。 BIP 002 指出硬叉 BIP“需要被整个比特币经济中采用”，包括比特币的持有者，以及那些用比特币提供服务的人。它承认这可能难以实现。 鉴于难以满足硬分叉 BIP 的要求，实际上没有一个 BIP 是通过硬分叉实现的。
只有当 BIP 成功地通过硬分叉或软分叉发起执行，并且在比特币协议中被实现时，才会被认为是达到了“最终”阶段。
比特币运行在一个由节点、用户、开发者和矿工们提供支持的分布式网络上。它是在没有任何能够控制协议方向的中心化机构的干预之下运行的。虽然在比特币上进行的交易是永久性的和不可篡改的，但为协议提供支持的底层技术正在持续精进。虽然协议通过工作量证明（PoW）挖矿进行最终交易确认，达成了关于交易的共识，但它也必须就如何随着时间的推移改进和更新协议达成不同类型的社会共识。
BIP 流程是开发人员如何以分布式和开源的方式进行协作以及对比特币作出贡献的关键。
以太坊在发展初期就借鉴了BIP协议，发展出了自己的EIP协议。
来自EIP-1：
EIP代表以太坊改进提案。EIP是一个设计文档，为以太坊社区提供信息，或描述以太坊或其过程或环境的新功能。EIP应提供该功能的简明技术规范和该功能的基本原理。EIP作者负责在社区内建立共识并记录不同意见。
Request for Comments（RFC）是一种用于为互联网引入技术和组织指南的方法，因为它们是由https://www.ietf.org[Internet Engineering Task Force]提出的。ERCS包括为以太坊网络设置标准的类似指南。以下部分提供了由以太坊开发人员社区开发和接受的最新列表。
ERCs的增加是通过增加EIP来对以太坊改进协议来完成的，这是对比特币自己的BIP的致敬。EIP由开发人员编写并提交给同行评审，评估其有用性，并且能够增加现有ERC的实用性。如果他们被接受，他们最终将成为ERC标准的一部分。下面简单列举了一些ERC。
| EIP/ERC | 标题 | 作者 | 层次 | 状态 |
|---|---|---|---|---|
| EIP-1 | EIP Purpose and Guidelines | Martin Becze, Hudson Jameson | Meta | Final |
| EIP-20 | ERC-20 Token Standard. Describes standard functions a token contract may implement to allow DApps and Wallets to handle tokens across multiple interfaces/DApps. Methods include: totalSupply(), balanceOf(address), transfer, transferFrom, approve, allowance. Events include: Transfer (triggered when tokens are transferred), Approval (triggered when approve is called). | Fabian Vogelsteller, Vitalik Buterin | ERC | Final |
| EIP-152 | Add BLAKE2 compression function F precompile |
Tjaden Hess, Matt Luongo, Piotr Dyraga, James Hancock (@MadeOfTin) | Core | Final |
| EIP-721 | ERC-721 Non-Fungible Token (NFT) Standard. It is a standard API that would allow smart contracts to operate as unique tradable non-fungible tokens (NFT) that may be tracked in standardised wallets and traded on exchanges as assets of value, similar to ERC-20. CryptoKitties was the first popularly-adopted implementation of a digital NFT in the Ethereum ecosystem. | William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs | Standard | Draft |
| EIP-1108 | Reduce alt_bn128 precompile gas costs | Antonio Salazar Cardozo, Zachary Williamson | Core | Final |
| EIP-1344 | ChainID opcode | Richard Meissner, Bryant Eisenbach | Core | Final |
| EIP-1844 | Repricing for trie-size-dependent opcodes | Martin Holst Swende | Core | Final |
| EIP-2028 | Transaction data gas cost reduction | Alexey Akhunov, Eli Ben Sasson, Tom Brand, Louis Guthmann , Avihu Levy | Core | Final |
| EIP-2200 | Structured Definitions for Net Gas Metering | Wei Tang | Core | Final |
与比特币从未进行硬分叉升级协议不同，以太坊多次采用硬分叉来升级协议，在以太坊公布的整体发展计划中，以太坊的发布分成四个阶段，即前沿（Frontier）、家园（Homestead）、大都会（Metropolis）和 宁静（Serenity）。当前（2020年1月），以太坊网络升级到 “大都会” 阶段。“大都会”升级需经过两次硬分叉，即“拜占庭”（ Byzantium ）和“君士坦丁堡”（ Constantinople ）。以太坊团队担心过快的升级到以太坊2.0会引起矿工社区的抵制造成不可挽回的影响，在“君士坦丁堡”升级之后又加入了一次硬分叉“伊斯坦布尔”，以此来平滑过渡到新的阶段。
太坊网络将在区块高度达到9,069,000时进行“伊斯坦布尔”升级，预计将于2019年12月7日（周六）左右发生，以太坊团队已经就即将到来的硬分叉中实施的以太坊改进提案达成共识，本次共有六个以太坊改进提案被接纳，分别是：
1、EIP-1108：降低alt_bn128预编译gas成本
2、EIP-1344：ChainID操作码
3、EIP-1884：重新定价trie-size-dependent操作码
4、EIP-2028：降低Calldata gas成本
5、EIP-152：Blake2压缩函数F预编译
6、EIP-2200：重新平衡净计量的SSTORE gas成本
表格中还列举了著名的ERC20提案，ERC20提案最初作为一种尝试，旨在为以太坊（Ethereum）上的token合约提供一个特征与接口的共同标准。ERC20 是各个代币的标准接口。ERC20 代币仅仅是以太坊代币的子集，为了充分兼容 ERC20，开发者需要将一组特定的函数（接口）集成到他们的智能合约中，以便在高层面能够执行这些操作：获得代币总供应量、获得账户余额、转让代币、批准花费代币。
ERC20 让以太坊区块链上的其他智能合约和去中心化应用之间无缝交互。一些具有部分但非所有ERC20标准功能的代币被认为是部分ERC20兼容，这还要视其具体缺失的功能而定，但总体是它们仍然很容易与外部交互。
但ERC20也有其缺点，ERC20令牌无法将令牌发送给一个与这些令牌不兼容的契约，正因为这样，使部分资金存在丢失的风险。曾出现过由于被发送到“错误”的合同上，大约价值40万美元的ERC20令牌被困。后续也有一些基于ERC20缺陷改进的提案，比如ERC777，ERC621等。更多的提案和细节可以通过以太坊EIP项目网站查看（ https://github.com/ethereum/EIPs ） 。