Ethereum es una plataforma que pretende permitir a la gente escribir fácilmente aplicaciones descentralizadas (Đapps) utilizando la tecnología blockchain. Una aplicación descentralizada es una aplicación que sirve para algún propósito específico a sus usuarios, pero que tiene la importante propiedad de que la propia aplicación no depende de la existencia de ninguna parte específica. En lugar de servir como un front-end para la venta o la prestación de servicios de una parte específica, una Đapp es una herramienta para que las personas y organizaciones en diferentes lados de una interacción utilicen para reunirse sin ningún intermediario centralizado.

Los contratos suelen servir para cuatro propósitos:

- Mantener un almacén de datos que represente algo que sea útil para otros contratos o para el mundo exterior; un ejemplo de ello es un contrato que simule una moneda, y otro es un contrato que registre la pertenencia a una determinada organización.

- Servir como una especie de cuenta de propiedad externa con una política de acceso más complicada; esto se denomina "contrato de reenvío" y suele implicar simplemente el reenvío de mensajes entrantes a algún destino deseado sólo si se cumplen ciertas condiciones; por ejemplo, se puede tener un contrato de reenvío que espere hasta que dos de tres claves privadas determinadas hayan confirmado un mensaje concreto antes de reenviarlo (es decir, multisig). Los contratos de reenvío más complejos tienen diferentes condiciones basadas en la naturaleza del mensaje enviado; el caso de uso más simple para esta funcionalidad es un límite de retirada que es anulable a través de algún procedimiento de acceso más complicado.

- Gestionar un contrato o relación en curso entre varios usuarios. Ejemplos de ello son un contrato financiero, un depósito de garantía con algún conjunto particular de mediadores, o algún tipo de seguro. También se puede tener un contrato abierto que una parte deja abierto para que cualquier otra parte se comprometa en cualquier momento; un ejemplo de esto es un contrato que paga automáticamente una recompensa a quien presenta una solución válida a algún problema matemático, o demuestra que está proporcionando algún recurso computacional.

- Proporcionar funciones a otros contratos; esencialmente servir como una biblioteca de software.

Los contratos interactúan entre sí a través de una actividad que se denomina alternativamente "llamada" o "envío de mensajes". Un "mensaje" es un objeto que contiene alguna cantidad de éter (una moneda interna especial utilizada en Ethereum con el propósito principal de pagar las tarifas de las transacciones), una matriz de bytes de datos de cualquier tamaño, las direcciones de un remitente y un destinatario. Cuando un contrato recibe un mensaje, tiene la opción de devolver algunos datos, que el remitente original del mensaje puede utilizar inmediatamente. De este modo, enviar un mensaje es exactamente como llamar a una función.

Modelo de complejidad sándwich: la arquitectura de nivel inferior de Ethereum debe ser lo más sencilla posible, y las interfaces con Ethereum (incluyendo los lenguajes de programación de alto nivel para los desarrolladores y la interfaz de usuario para los usuarios) deben ser lo más fáciles de entender. Cuando la complejidad sea inevitable, debe ser empujada a las "capas intermedias" del protocolo, que no forman parte del núcleo del consenso pero que tampoco son vistas por los usuarios finales - compiladores de lenguajes de alto nivel, scripts de serialización y deserialización de argumentos, modelos de estructuras de datos de almacenamiento, la interfaz de almacenamiento leveldb y el protocolo wire, etc. Sin embargo, esta preferencia no es absoluta.

Libertad: los usuarios no deben verse limitados en el uso del protocolo de Ethereum, y no debemos intentar favorecer o desfavorecer ciertos tipos de contratos o transacciones de Ethereum basándonos en la naturaleza de su propósito. Esto es similar al principio que guía el concepto de "neutralidad de la red". Un ejemplo de este principio que no se sigue es la situación en el protocolo de transacciones del bitcoin, donde se desaconseja el uso de la blockchain para fines "extraños" (por ejemplo, almacenamiento de datos, meta-protocolos), y en algunos casos se realizan cambios explícitos en el cuasi-protocolo (por ejemplo, la restricción de OP_RETURN a 40 bytes) para intentar atacar a las aplicaciones que utilizan la blockchain de forma "no autorizada". En Ethereum, en cambio, estamos muy a favor de establecer las tarifas de las transacciones de manera que sean aproximadamente compatibles con los incentivos, de manera que los usuarios que utilizan la cadena de bloques de manera que produzcan hinchazón internalicen el coste de sus actividades (es decir, impuestos pigovianos).

Generalización: las características de los protocolos y los códigos operativos de Ethereum deben incorporar el máximo de conceptos de bajo nivel, de modo que puedan combinarse de forma arbitraria, incluyendo formas que pueden no parecer útiles hoy pero que pueden serlo más adelante, y de modo que un conjunto de conceptos de bajo nivel pueda hacerse más eficiente eliminando parte de su funcionalidad cuando no sea necesaria. Un ejemplo de este principio es nuestra elección de un opcode LOG como forma de alimentar de información a las dapps (especialmente a las de clientes ligeros), en lugar de simplemente registrar todas las transacciones y mensajes como se sugirió internamente antes - el concepto de "mensaje" es realmente la aglomeración de múltiples conceptos, incluyendo "llamada a una función" y "evento interesante para observadores externos", y vale la pena separar los dos.

No tener características: como corolario de la generalización, el equipo de desarrollo a menudo se niega a construir incluso casos de uso de alto nivel muy comunes como partes intrínsecas del protocolo, en el entendimiento de que si la gente realmente quiere hacerlo siempre puede crear un subprotocolo (por ejemplo, submoneda respaldada por éter, bitcoin/litecoin/dogecoin sidechain, etc) dentro de un contrato. Un ejemplo de esto es la falta de una función de "tiempo de bloqueo" similar a la de Bitcoin en Ethereum, ya que dicha función puede simularse a través de un protocolo en el que los usuarios envían "paquetes de datos firmados" y esos paquetes de datos pueden introducirse en un contrato especializado que los procesa y realiza alguna función correspondiente si el paquete de datos es válido en algún sentido específico del contrato.No aversión al riesgo: el equipo de desarrollo está de acuerdo con un mayor grado de riesgo si un cambio que lo incremente proporciona beneficios muy sustanciales (por ejemplo, transiciones de estado generalizadas, tiempos de bloqueo 50 veces más rápidos, eficiencia de consenso, etc.)