This post is about smart property and Internet of Things with respect to interacting with Ethereum. In many cases of interacting with smart property, you want the smart property itself to host an externally-owned account or a contract account. Let's take the case of where smart property itself is sending a transaction into Ethereum. What you really want is to be able to run an Ethereum client in a resource-constrained/embedded environment (i.e. smart property) like a refrigerator, smart sensor, etc. Otherwise, if the smart property does not have its own Ethereum client (entirely possible), it will have to send its own out-of-band request to some centralized node that, in turn, is the node running the Ethereum client and tied to an account -- so only this centralized node can send transactions into Ethereum. So, to reiterate, smart property without its own Ethereum client necessitates a client-server model with respect to interacting with Ethereum...that's not very decentralized.
This begs the question of whether we should assess how we build the Ethereum clients. Should we modularize them so that we can, for example, have a client that can only send transactions but that doesn't need to mine? Having modules reduces code size and allows for defining only what is necessary to interact with the Ethereum ecosystem for a specific context.
This begs another question about Ethereum wire protocol. I wonder if TCP is a bit heavyweight since that can be resource-intensive. For example, maidsafe has chosen RUDP for scaling and other considerations: http://maidsafe.net/libraries-reliable-udp
. But it doesn't have to be either/or; maybe different kinds of connection protocols can be supported depending on where the Ethereum client lives. I heard that Go (and of course C++) can be applied to these kinds of environments so we may already have a running start here.